Est-ce que NT AUTHORITY \ System doit avoir le rôle sysadmin?

Question

Je n'arrive pas à trouver une réponse définitive à cette question. Le problème: J'utilise Octopus Deploy pour exécuter un exécutable qui exécutera mes scripts de migration de base de données. Une erreur se produit lorsque le service Windows Octopus "Tentacle" s'exécute en tant que localsystem, ce qui se traduit par NT AUTHORITY\System.

Une solution consiste à modifier les paramètres de sécurité du serveur SQL et à accorder un rôle approprié à l'utilisateur NT AUTHORITY\System, ce qui permet à un utilisateur s'exécutant en tant qu'utilisateur localsystem de créer la base de données.

Quelles sont les implications de cette modification pour la sécurité? Cela permettrait à tout processus exécuté sous localsystem d'effectuer des opérations sur la base de données, mais est-ce une mauvaise chose étant donné que je contrôle ce qui est installé sur le serveur?

Il semblerait qu'il y ait eu une modification faite autour de SQL Server 2012 où par le compte localsystem était précédemment par défaut un sysadmin mais cela a été changé. Une chose que j'ai vu était que cette modification empêche les administrateurs de serveur d'avoir accès au serveur mais je ne vois pas comment cela est possible étant donné que vous ne pouvez pas vous connecter en tant que localsystem de toute façon.

Qu'est-ce qui me manque?

Références:

https://support.microsoft.com/en-us/help/932881/how-to-make-unwanted-access-to-sql-server-2005-by-an-operating-system

https://dba.stackexchange.com/questions/142166/grant-sysadmin-permissions-to-nt-authority-system

https://serverfault.com/questions/130958/implications-and-benefits-of-removing-nt-authority-system-from-sysadmin-role

Answer 1

Je réponds à celui-ci:

Une chose que j'ai vu était que ce changement empêche les administrateurs de serveur avoir accès au serveur, mais je ne vois pas comment cela est possible compte tenu de que vous ne pouvez pas vous connecter en tant que système locals de toute façon.

administrateur Windows local peut accéder à toute façon le serveur, le lancement de SQL Server en mode mono-utilisateur, il aura un plein contrôle sur elle: Connect to SQL Server When System Administrators Are Locked Out

Mais cela exige que le serveur soit redémarré.

Une autre option pour accéder au serveur en tant que sysadmin sans redémarrer est d'utiliser PsExec (-s): vous pouvez vous connecter en tant que système local même via SSMS. Et si ce login est un sysadmin, vous avez un contrôle total sur le serveur

Answer 2

Si quelqu'un est capable de compromettre votre instance d'Octopus Deploy, le rôle SA fournit un accès suffisant pour supprimer toutes les bases de données sur votre serveur. J'imagine que la création de la base de données initiale est un événement Blue Moon. Une option plus sûre consiste à créer manuellement la base de données et accorder à NT Authority le moins de privilèges possible pour exécuter vos scripts de migration.

Nous avons pris cette approche et a travaillé de retour de SA, à db_owner, à un rôle personnalisé avec

[db_datareader] 
[db_datawriter] 
[db_ddladmin]