none
Sécuriser les accès BdeD sql server RRS feed

  • Question

  • Bonjour, 

    Je travaille actuellement sur une nouvelle application qui utilisera une BdeD SQL Server. SQL Server est déjà installé et comporte déjà plusieurs bases géré par l'administrateur sa.

    Dans mon cas, je ne souhaite pas que sa puisse avoir un quelconque droit sur ma nouvelle base de donnée, et je ne souhaite pas non plus mettre en péril les BdeD déjà installées.

    Aussi, afin de pallier à ces soucis, j'ai installé une deuxième instance SQL et renommé la connexion sa. Ainsi, sa ne peux plus se connecter à ma base. Par ailleurs, j'ai conservé uniquement la connexion sa et des connexions créées par moi uniquement afin de ne plus permettre d'authentification windows. 

    Donc, dans la mesure où je débute, j'aurai souhaité savoir ce que vous pensiez de cette façon de procéder. Y a t-il des solutions plus intéressantes? Si oui, pouvez vous  me faire part de votre expérience.

    Concrètement, je veux crée un admin connu uniquement de moi, et des utilisateurs qui viendront se connecter à partir de mon appli.

    Merci d'avance


    carribean
    lundi 4 avril 2011 12:03

Réponses

  • Pourquoi un tel besoin supprimer l'accès au login SQL SA ?

    Généralement, pour une installation SQL Server :

    - soit on est en mode sécurité windows uniquement => pbm du compte SA réglé

    - soit on est en mode sécurité mixte => sa doit avoir unmot de passe fort et on ne se sert plus jamais de se compte, on l'oublie ...

    Ensuite, il faut que quelques personnes (un groupe Windows par exemple) ait les droits suffisents sur l'instance pour administer celle ci. Donc ce groupe va appratenir au role fixe de niveau serveur SYSADMIN. Et là, en l'état actuel des choses, il se sera pas possible de supprimer la visualisation des données à ce role fixe serveur.

    Par contre, il est tout a fait envisageable (a faire absolument sur un SQL2005 et <) de supprimer le groupe local administrators du serveur de ce role fixe SYSADMIN.

    Pour ma ta stratégie comporte un risque : un et un seul admin ... Si demain, tu es malade, sans voulior penser pire, que se passe t'il pour l'application ? Mon conseil, en administration, tarvaille toujours avec des groupes ... Et régules en les membres. Ensuite, joue avec les audits (si SQL 2005) ou des triggers afin de controler l'accès si c'est ça ton soucis.

     

    Christophe

    lundi 4 avril 2011 12:28
  • Bonjour,

    Donner les droits sysadmin aux applications est absurde et qu'il existe un réel problème de sécurité dans ce cas .. mais bon dans les faits on arrive souvent à cela.

    Dans votre cas j'installerais une instance distincte, ce qui vous permettra d'isoler votre architecture en terme de sécurité. Par contre je ne supprimerais pas les groupes créés par SQL Server lors de l'installation. Comme Christophe je pense que la notion de groupe est importante. Il est plus facile de gérer la sécurité d'un groupe pour les raisons cités plus haut.

    Cependant l'idée de renommer le compte sa n'est pas une mauvaise chose en soi surtout en terme de sécurité. En effet, la plupart des attaques sur SQL Server se focalisent sur le port par défaut du serveur SQL (1433) et sur le compte sa (qui est un compte prédéfini et implicement connu des hackers). Le fait d'avoir une politique de mot de passe forte limite les problèmes mais ne les résoud pas forcément d'autant plus que dans la plupart des entreprises il n'existe aucune implémentation de systèmes d'audit ou autres ..

    ++


    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    mercredi 6 avril 2011 09:24
    Modérateur
  • Bonjour,

    Par principe, il faut séparer les comptes d'administration tels que sa et les comptes des utilisateurs accédant aux bases de données par l'intermédiaire d'une application comme l'a très bien expliqué mikedavem.

    Supprimer l'accés à une base de données à sa est presque aussi aberrant puis un sa a tous les droits sur l'instance SQL Server et peut à tout moment s'octroyer toutes les permissions qu'il veut sur une base de données , ses tables,ses procédures stockées ...

    Par contre, je me souviens qu'il peut y avoir de sérieux problèmes quand on renomme le compte sa ( déjà le sauvetage par DAC quand le serveur est devenu inaccessible voir la facette RemoteDacEnabled )

    Une solution ( pas très belle ) mais assez efficace est d'utiliser la notion de port dynamique , qui évite le port 1433 et qui est la plus simple en cas d'installation de plusieurs instances SQL Server sur la même machine.

    Bonne journée


    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.
    jeudi 7 avril 2011 21:49

Toutes les réponses

  • Pourquoi un tel besoin supprimer l'accès au login SQL SA ?

    Généralement, pour une installation SQL Server :

    - soit on est en mode sécurité windows uniquement => pbm du compte SA réglé

    - soit on est en mode sécurité mixte => sa doit avoir unmot de passe fort et on ne se sert plus jamais de se compte, on l'oublie ...

    Ensuite, il faut que quelques personnes (un groupe Windows par exemple) ait les droits suffisents sur l'instance pour administer celle ci. Donc ce groupe va appratenir au role fixe de niveau serveur SYSADMIN. Et là, en l'état actuel des choses, il se sera pas possible de supprimer la visualisation des données à ce role fixe serveur.

    Par contre, il est tout a fait envisageable (a faire absolument sur un SQL2005 et <) de supprimer le groupe local administrators du serveur de ce role fixe SYSADMIN.

    Pour ma ta stratégie comporte un risque : un et un seul admin ... Si demain, tu es malade, sans voulior penser pire, que se passe t'il pour l'application ? Mon conseil, en administration, tarvaille toujours avec des groupes ... Et régules en les membres. Ensuite, joue avec les audits (si SQL 2005) ou des triggers afin de controler l'accès si c'est ça ton soucis.

     

    Christophe

    lundi 4 avril 2011 12:28
  • Merci de ta réponse.

    En fait, lorsque je parle d'un administrateur "sa" unique, celui ci concerne notre société entière donc pas de souci même s'il m'arrive quelque chose... Notre souci premier vient du fait que nous sommes en pleine réécriture d'une appli qui devra être installée chez des clients. Ces clients possèdent déjà ,parfois, des instances SQL server dont le mot de passe "sa" est déjà utilisé par d'autres entreprises (concurrentes ou pas) or nous ne souhaitons pas que ces derniers puissent avoir un accès à nos tables à avec le standard "sa" et ainsi en déduire l'architecture. 

    La solution envisagée était donc celle que j'ai présenté précédemment.

    Quant au mode de sécurité windows, nous ne sommes pas administrateur des machines clientes, c'est pourquoi nous avions fait le choix du mode sécurité mixte en prenant soins  de supprimer les connexions créées par défaut (AUTORITE NT\SYSTEM, BUILTIN\Administrateurs, SQLServer2005MSFTEUser$..., SQLServer2005MSSQLUserser$...)

    Ainsi seules la connexion "sa" renommée et les connexions/utilisateurs que nous avions créé nous permettait de nous connecter en mode mixte : A partir de l'appli ou directement de visual studio)

    Nous débutons et sommes preneurs de toute information, là nous étudions les utilisateurs, les schémas... afin d'obtenir des utilisateurs qui seront developpeurs, simples utilisateurs, ou demo.

     

     


    carribean
    lundi 4 avril 2011 13:16
  • Bonjour,

    Donner les droits sysadmin aux applications est absurde et qu'il existe un réel problème de sécurité dans ce cas .. mais bon dans les faits on arrive souvent à cela.

    Dans votre cas j'installerais une instance distincte, ce qui vous permettra d'isoler votre architecture en terme de sécurité. Par contre je ne supprimerais pas les groupes créés par SQL Server lors de l'installation. Comme Christophe je pense que la notion de groupe est importante. Il est plus facile de gérer la sécurité d'un groupe pour les raisons cités plus haut.

    Cependant l'idée de renommer le compte sa n'est pas une mauvaise chose en soi surtout en terme de sécurité. En effet, la plupart des attaques sur SQL Server se focalisent sur le port par défaut du serveur SQL (1433) et sur le compte sa (qui est un compte prédéfini et implicement connu des hackers). Le fait d'avoir une politique de mot de passe forte limite les problèmes mais ne les résoud pas forcément d'autant plus que dans la plupart des entreprises il n'existe aucune implémentation de systèmes d'audit ou autres ..

    ++


    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    mercredi 6 avril 2011 09:24
    Modérateur
  • Bonjour,

    Par principe, il faut séparer les comptes d'administration tels que sa et les comptes des utilisateurs accédant aux bases de données par l'intermédiaire d'une application comme l'a très bien expliqué mikedavem.

    Supprimer l'accés à une base de données à sa est presque aussi aberrant puis un sa a tous les droits sur l'instance SQL Server et peut à tout moment s'octroyer toutes les permissions qu'il veut sur une base de données , ses tables,ses procédures stockées ...

    Par contre, je me souviens qu'il peut y avoir de sérieux problèmes quand on renomme le compte sa ( déjà le sauvetage par DAC quand le serveur est devenu inaccessible voir la facette RemoteDacEnabled )

    Une solution ( pas très belle ) mais assez efficace est d'utiliser la notion de port dynamique , qui évite le port 1433 et qui est la plus simple en cas d'installation de plusieurs instances SQL Server sur la même machine.

    Bonne journée


    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.
    jeudi 7 avril 2011 21:49