Datafly.pro

SQL Server vous offre deux modes d’authentification :

• Authentification Windows (ou approuvée) : SQL Server valide l’utilisateur par son compte d’ouverture de session Windows (avec le jeton d’authentification du système d’exploitation).
• Authentification SQL Server : SQL Server valide l’utilisateur à l’aide d’informations de login et mot de passe stockées dans ses tables système, indépendamment de son compte Windows.

Vous pouvez choisir le mode d’authentification supporté par l’instance :

• Authentification Windows (proposé par défaut à l’installation) : ce mode désactive l’authentification SQL Server.
• Authentification mixte (SQL Server et Windows) : accepte l’authentification SQL Server et l’authentification Windows.

Tout nous pousse à choisir l’authentification Windows. Comme le cite l’aide en ligne : « L'authentification Windows, qui est le mode d'authentification par défaut, offre une sécurité très supérieure à l'authentification SQL Server. L'authentification Windows utilise le protocole de sécurité Kerberos, met en œuvre des stratégies de mot de passe portant sur la validation de la complexité des mots de passe forts et prend en charge le verrouillage des comptes et l'expiration des mots de passe. (...) Remarque relative à la sécurité :  lorsque c'est possible, utilisez l'authentification Windows. »

Mais une des failles de sécurité trop souvent constatée lors de mes consultations est de configurer ses utilisateurs en authentification Windows sans que soit mis en place un quelconque mécanisme de sécurité.

Bien sûr, les conclusions de l'audit de sécurité officiel vous recommandent peut-être d'utiliser l'authentification Windows plutôt que celle de SQL Server. Mais l’auditeur, ignare en ce qui concerne SQL Server, n’a pas pensé que vous permettiez ainsi à vos utilisateurs d’accéder aux données avec leurs outils bureautiques, munis des larges permissions qui sont bien souvent nécessaires au fonctionnement de votre application cliente : ainsi, Excel ou Access (voire Word !) leur permettent d’accéder aux précieuses données, pour le moins en lecture, voire en modification ! Sans parler d’une légion de freewares susceptibles d’être installés sur leur poste de travail...

Quelles solutions à ce trou de sécurité ?

L’authentification SQL Server

On peut bien entendu choisir de rester en authentification SQL Server, avec les inconvénients de cette solution : mots de passe généralement accessibles et sécurité moindre, pas d’annuaire centralisé ni de SSO...

Les rôles d’application

On peut aussi utiliser les rôles d’application : une fois la connexion établie avec le login de l’utilisateur, l’application configure son contexte de sécurité en activant un rôle d’application grâce à la commande EXEC sp_setapprole [ @rolename = ] 'role',    [ @password = ] ‘password’ (le password peut être chiffré). Cette méthode a aussi nombre d’inconvénients :

• L’utilisation de rôles d’applications doit avoir été pensée lors de la conception de l’application. Donc inutilisable pour un progiciel qui n’a pas prévu cette fonctionnalité.
• Le rôle d’application est une entité de sécurité au niveau de la base de données. Il est donc nécessaire d’avoir un rôle dans chaque base de données accédée. Cela interdit d’accéder à plusieurs bases de données dans une même connexion (en faisant référence à des objets d’une autre base dans la même connexion, sauf utilisation de l’utilisateur Guest), de même il n’est pas possible de faire un USE pour changer de base de données active une fois le rôle activé.
• Un problème peut aussi se poser avec les applications reposant sur OLE-DB qui font du ressource pooling (réutilisation des connexions qui sont maintenues ouvertes). Cela nécessite de désactiver la fonctionnalité au niveau OLE-DB comme l’indique la KB229564.
• L’utilisateur Windows a tout de même accès à SQL Server, même s’il n’accède pas aux données il peut connaitre la version de SQL Server (SELECT @@VERSION) et ses éventuelles vulnérabilités.
• Enfin, le rôle d’application est protégé par un mot de passe et cette unique protection est en elle-même une limite à la sécurité.

Le Logon Trigger

Autre possibilité : n’accepter que les connexions issues des applications référencées. Le logon trigger nous permet de mettre en place ce contrôle dès la connexion. Si l'utilisateur indique dans sa connexion une application qui ne fait pas partie de la liste, sa connexion n'aboutit pas. (On pourrait aussi envisager un mécanisme asynchrone qui déconnecterait l'utilisateur après coup en utilisant les notifications d'évènement)

A noter que ce n’est pas imparable non plus : un utilisateur pourrait modifier sa chaine de connexion pour imiter une application autorisée...

Un exemple de logon trigger :

CREATE TRIGGER [logoncontrolTR] ON ALL SERVER
    WITH EXECUTE AS 'sa'
    FOR LOGON
AS
    BEGIN
        IF ORIGINAL_LOGIN() <> 'special_login'  -- login autorisé à ttes les applis
            AND IS_SRVROLEMEMBER('sysadmin', ORIGINAL_LOGIN()) = 0  -- non sysadmin
            AND NOT EXISTS ( SELECT *
                             from   master.dbo.AuthorizedApps
                             where  APP_NAME() like AppName + '%' ) -- appli non autorisée
            BEGIN        
                DECLARE @DataTrigger XML          
                SET @DataTrigger = EVENTDATA() ;
                ROLLBACK 
                INSERT  INTO master..logoncontrol
                        SELECT  @DataTrigger.value('(/EVENT_INSTANCE/LoginName)[1]',
                                                   'varchar(50)')
                              , @DataTrigger.value('(/EVENT_INSTANCE/LoginType)[1]',
                                                   'varchar(50)')
                              , @DataTrigger.value('(/EVENT_INSTANCE/PostTime)[1]',
                                                   'datetime')
                              , @DataTrigger.value('(/EVENT_INSTANCE/ClientHost)[1]',
                                                   'varchar(50)')
                              , @DataTrigger.value('(/EVENT_INSTANCE/SPID)[1]',
                                                   'int')
                              , APP_NAME()         
            END
    END ;
GO