Suppression des comptes NT AUTHORITY et NT SERVICE créés automatiquement

J'ai donc récemment déplacé des travaux - un morceau de code que j'ai repéré dans nos scripts de construction pour les nouvelles installations SQL Server est ci-dessous.

IF EXISTS ( SELECT  *
            FROM    [sys].[syslogins]
            WHERE   [name] = N'NT AUTHORITY\SYSTEM' )
    BEGIN
        DROP LOGIN [NT AUTHORITY\SYSTEM];
    END

IF EXISTS ( SELECT  *
            FROM    [sys].[syslogins]
            WHERE   [name] = N'NT SERVICE\SQLWriter' )
    BEGIN
        DROP LOGIN [NT SERVICE\SQLWriter];
    END

IF EXISTS ( SELECT  *
            FROM    [sys].[syslogins]
            WHERE   [name] = N'NT SERVICE\Winmgmt' )
    BEGIN
        DROP LOGIN [NT SERVICE\Winmgmt];
    END
GO

Ces comptes sont créés par défaut lors du processus d'installation de SQL Server.

La suppression des connexions ci-dessus est-elle recommandée? Y a-t-il des effets secondaires que cela pourrait causer? À quoi servent ces connexions?

Je lis Puis-je supprimer les connexions NT SERVICE \ SQLWriter et NT SERVICE \ Winmgmt? mais ce n'est tout simplement pas assez concret - je peux voir à quoi ils servent, mais très peu d'autre. Ont-ils besoin d'un accès administrateur système? etc.

À titre d'exemple (tiré de Configurer les comptes de service Windows et les autorisations ):

Le système local est un compte intégré très privilégié. Il dispose de privilèges étendus sur le système local et agit comme ordinateur sur le réseau. Le nom réel du compte est NT AUTHORITY\SYSTEM.

Comment dois-je lire ceci? Doit-on lui laisser ces privilèges "élevés"?

Avant de voter, voici une documentation formelle à laquelle vous pouvez vous référer pour une raison légitime pour laquelle ces comptes seraient scriptés comme vous le voyez: Règle STIG SV-53421r2_rule . Ces contrôles sont spécifiques à la version de SQL Server, mais il existe également un certain nombre d'autres contrôles dans les versions les plus récentes. Si vous travaillez pour une organisation qui relève de ces contrôles et adhère également à certaines des plus strictes, telles que la révocation des subventions par défaut accordées au rôle public, les choses peuvent se compliquer assez rapidement.

Comme je l' ai une certaine expérience dans un environnement qui relève de ces contrôles, je peux dire que vous pouvez désactiver / déposer à la fois les NT SERVICE\SQLWriteret NT SERVICE\Winmgmtcomptes pur et simple, mais vous devez vous assurer que votre service SQL Server est en cours d' exécution sous un compte de service approprié avec le niveau du système d'exploitation suffisant des autorisations, comme un compte de service de domaine suffisamment verrouillé, ou mieux encore, des comptes de service gérés autonomes ou de groupe . Encore une fois, les autorisations du système d'exploitation doivent être traitées avec soin car cela s'aventure sur le territoire du château de cartes si vous n'effectuez pas de tests suffisants.

Quant au NT AUTHORITY\SYSTEMcompte, ce n'est PAS un compte que vous souhaitez supprimer si vous allez exécuter des groupes de disponibilité. En fait, STIG SV-93835r1_rule mentionne que vous devez le conserver avec uniquement les CONNECT SQLautorisations accordées par défaut. Si vous disposez d'un groupe de disponibilité, ce compte devra également disposer des autorisations supplémentaires suivantes:

• MODIFIER TOUT GROUPE DE DISPONIBILITÉ
• VOIR L'ÉTAT DU SERVEUR
• EXECUTE ON [sys]. [Sp_server_diagnostics]
• EXECUTE ON [sys]. [Sp_availability_group_command_internal]

Ces restrictions peuvent être une douleur royale, mais il existe des raisons légitimes de limiter leur utilisation et leurs autorisations. Si vous ne respectez pas ces directives, faites-vous plaisir et commentez ces étapes.

J'espère que cela pourra aider!