SQL Server et la sécurité

1 118 vues

Publié le

JSS2011 - SQL Server et la sécurité

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 118
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
63
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Firewall
    périphérique hardware ou software qui autorise ou bloque le trafic réseau (ACL)
    Fournit une protection contre les attaques de type DDoS

    Architecture des réseaux
    Exposition au réseau internet
    Utilisation de DMZ

    Chiffrement de la connexion
    Empêcher les sniffers de réseau
  • MPIO
    Chiffrement des blocs de données mais pas du bloc d’adresse

    RKM
    RSA Key Manager

    MPIO : Impact sur les performances
    la charge de travail est traitée par les processeurs du serveur de bases de données
    Peut être consommateur de ressources si la charge transactionnelle est importante

  • Nécessité d’être administrateur local de la machine pour installer SQL Server 2000
  • Détachement
    SQL Server tente de configurer les ACL NTFS pour le compte utilisateur à l’origine de l’opération. Les autres ACL sont supprimées.
    Si le compte ne peut être configuré (Login SQL Server) les ACL sont configurés pour le compte de service et le groupe administrateur

    Attachement
    SQL Server paramètre automatiquement les ACL nécessaires pour le compte de service SQL et éventuellement pour le groupe administrateur local (si le moteur a accès aux fichiers)
    Si l’identité du compte ne peut être emprunté (SQL Server Login) c’est le compte de service SQL qui est utilisé

  • LOCAL SYSTEM
    Privilèges élevés
    Les applications utilisant ce compte ont un accès à l’instance SQL Server

    Compte utilisateur partargé
    Accès mutuel aux ressources de chaque instance qui possède le même compte utilisateur
    Accès non maitrisé aux ressources des instances SQL Server

  • Comptes managés et comptes virtuels
    Avantages :
    Gestion des mots de passes automatique
    Gestion des SPN automatique
    Compte ne pouvant être utilisé que sur un seul ordinateur
  • SQL Browser et désactivation :
    Réduit la surface d’attaque
    Limite la portée des attaques (SQL Slammer par exemple)
  • Politique de sécurité des mots de passe :
    Vérifier que la politique de sécurité est bien appliquée sur le serveur qui héberge SQL Server
  • Avantages des rôles ?
    Gestion centralisée des permissions au travers d’un seul «conteneur»
    Administration simplifiée et contrôlée
    Quand utiliser les rôles ?
    Un ensemble de privilèges similaires sont affectés à plusieurs principales
  • Qu’est-ce qu’un schéma ?
    Conteneur logique d’objets (tables, vues, procédures, fonctions, types etc…)
  • L’implémentation d’une solution d’audit personnalisée avant SQL Server 2008 passe par la mise en place :
    Des audits des logins (FAILED par défaut)
    De l’utilisation des triggers de serveurs, logins et DDL
    Des traces profiler
  • L’implémentation d’une solution d’audit personnalisée avant SQL Server 2008 passe par la mise en place :
    Des audits des logins (FAILED par défaut)
    De l’utilisation des triggers de serveurs, logins et DDL
    Des traces profiler
  • L’implémentation d’une solution d’audit personnalisée avant SQL Server 2008 passe par la mise en place :
    Des audits des logins (FAILED par défaut)
    De l’utilisation des triggers de serveurs, logins et DDL
    Des traces profiler
  • SQL Server et la sécurité

    1. 1. LA SÉCURITÉ DANS SQL SERVER ET LES NOUVEAUTÉS DE LA VERSION 2012
    2. 2. Rejoignez la Communauté
    3. 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. 4. SOMMAIRE •SQL Server et son environnement •Sécuriser une instance SQL Server •Sécurité des sauvegardes •Audits 4
    5. 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. 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. 7. SQL SLAMMER LE DEBUT D’UNE PRISE DE CONSCIENCE DE LA SECURITE 7
    8. 8. SQL SERVER ET SON ENVIRONNEMENT 8
    9. 9. SQL SERVER ET SON ENVIRONNEMENT 9 Réseau Stockage Windows SQL Server
    10. 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. 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. 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. 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. 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. 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. 16. SECURISER UNE INSTANCE SQLSERVER 1
    17. 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. 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. 19. SECURISER UNE INSTANCE SQLSERVER 1
    20. 20. SECURISER UNE INSTANCE SQLSERVER 2
    21. 21. SECURISER UNE INSTANCE SQLSERVER 2
    22. 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. 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. 24. SECURISER UNE INSTANCE SQLSERVER 2
    25. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 36. SECURITE DES SAUVEGARDES 3
    37. 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. 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. 39. AUDITS 3
    40. 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. 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. 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. 43. AUDITS 4
    44. 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. 45. DEMO Q & A
    46. 46. Merci à nos Sponsors Rencontrez les dans l’espace partenaires

    ×