Restreindre l'accès à l'administrateur Windows

Comme le disent les meilleures pratiques SQL Server , « le mode d'authentification Windows est plus sécurisé que l'authentification SQL ». Et maintenant, je veux savoir: existe-t-il un moyen de protéger SQL Server des utilisateurs avec des droits d'administrateur Windows?

Non.

Si un utilisateur est administrateur Windows d'une boîte, supposez qu'il possède tout sur la boîte (y compris SQL Server). Avec les droits d'administrateur Windows, il est trivial de contourner toute protection ciblée que vous appliquez (comme un déclencheur de connexion qui identifie leur nom d'utilisateur), en usurpant l'identité d'une autre personne (y compris NT AUTHORITY\SYSTEM, qui obtient de facto des droits d'administrateur sur toutes les instances locales de SQL Server ). L'audit n'aidera pas beaucoup non plus, car ils peuvent facilement désactiver cela, mais vous devriez l'avoir juste au cas où.

Si vous ne faites pas confiance à quelqu'un, ne lui donnez pas de droits d'administrateur Windows, point final.

Non, il n'est pas possible d'empêcher complètement les administrateurs locaux d' sysadminaccéder à une instance SQL Server.

Si l'instance est redémarrée en mode mono-utilisateur , SQL Server est codé en dur pour accorder des sysadminprivilèges d' administrateur local , même s'il peut ne pas y avoir de connexion explicite. La raison pour laquelle cela existe est à des fins de récupération car il est possible de vous verrouiller hors d'une instance.

Cela dit, restreindre l'accès pendant que l'instance s'exécute en mode multi-utilisateur (sans interruption de service) n'est pas aussi difficile. Comme Aaron l'a mentionné, les administrateurs locaux peuvent emprunter l'identité NT AUTHORITY\SYSTEM, qui par défaut a une sysadminconnexion de niveau créée dans SQL Server 2008. Cela pourrait être exploité pour récupérer l' sysadminaccès pendant que le serveur est en cours d'exécution. (Remarque: dans SQL Server 2012, cette connexion n'est plus sysadmin.) Je ne sais pas exactement à quoi cette connexion est utilisée (mises à niveau / correctifs / etc., probablement), mais je pense qu'il est sûr de la désactiver, sauf pendant ces événements. S'il n'y a pas d'autres connexions impersonnables, cela devrait être suffisant pour refuser l'accès. Encore une fois, uniquement si l'instance est en cours d'exécution, sans interruption .

Par défaut dans SQL 2008 et 2012, il n'y a pas d'accès par défaut pour les administrateurs Windows à un serveur SQL. Pour qu'un administrateur Windows (c'est-à-dire, quelqu'un qui est soit un administrateur de domaine ou un administrateur local) ait accès, leur connexion doit être explicitement autorisée à accéder ou le groupe auquel ils appartiennent ainsi que les droits dans SQL Server lui-même. Lors de la configuration de l'instance, vous devez spécifier une connexion ou un groupe Active Directory en tant qu'administrateur, mais cette connexion / ce groupe peut être n'importe qui dans votre domaine.

Dans SQL 2005, il y avait un BUILTIN\Administratorsgroupe avec des droits d'accès sysadmin. Ce groupe permettrait aux administrateurs locaux d'accéder à SQL Server en tant qu'administrateur système. Ce groupe peut être supprimé de SQL Server et il a été jugé préférable de le faire.

Cela étant dit, il n'y a aucun moyen d'empêcher Windows (local ou domaine) d'affecter le serveur sur lequel SQL Server vit. Cela signifie que les administrateurs peuvent toujours affecter les services et les configurations au niveau du système d'exploitation, modifier la sécurité des répertoires et d'autres tâches au niveau du système d'exploitation. C'est, après tout, pourquoi ils sont administrateurs Windows.

En général, vous devez faire confiance à vos administrateurs, à la fois SQL Server et Windows. Bien que les administrateurs Windows ne puissent pas effectuer de tâches ou accéder aux données (par défaut) dans le serveur SQL lui-même, ils contrôlent toujours l'environnement dans lequel se trouve votre serveur SQL. Vous devez faire attention à qui vous affectez à ces rôles.