La réponse précédente ne semblait pas répondre directement aux questions, j'ai donc pensé y ajouter quelque chose.
- Mon plan consiste à exécuter le service en tant que compte «Service local» par défaut. Je vais définir explicitement les privilèges "Contrôle total" pour le compte "Service local" sur le dossier que je lis / écris vers et depuis. Je pense que ce qui précède est un bon plan.
Personnellement, je ne vois pas de gros problème avec ce plan. Avec BUILTINs, le choix est entre:
- Exécution en tant que LOCALSYSTEM - donc si ce service est compromis, l'attaquant possède Tout , et immédiatement.
- Exécution en tant que LOCALSERVICE - donc si ce service, ou l'un des nombreux autres services exécutés sous ce compte, est compromis, l'attaquant a accès à un répertoire supplémentaire. *
On peut dire que l'ajout de quelques ACL supplémentaires pour pouvoir utiliser la deuxième option est préférable. Oui, l'option la plus sûre pour un service à faible privilège mais hautement sensible à la sécurité serait de s'exécuter sous un compte de service personnalisé à faible privilège. Mais à moins que vous ne vouliez créer un nouveau compte / gérer les mots de passe pour chaque service que vous déployez, l'utilisation de LocalService pour des tâches non sensibles mineures n'est pas si terrible. Vous avez juste besoin de prendre une décision responsable sur la base de ces considérations, comme ce qui se trouve dans ce répertoire ou cette base de données, l'impact en cas de violation, etc.
Bien que, encore une fois, par principe de privilège minimum, vous ne devez définir que Full Controlsi ce Modifyn'est vraiment pas suffisant.
2. Ma question est la suivante: pour le dossier dans lequel je lis et j'écris, dois-je configurer un rôle "Service réseau" avec un accès de contrôle total? Je me demande, puisque mon service utilise la connectivité de la base de données à un autre serveur, si j'ai besoin de la configuration du compte "Service réseau".
Si votre base de données nécessite une connexion Windows Integrated / SSPI, alors oui, vous devrez utiliser NetworkService (ou un compte de service de domaine) partout, c'est-à-dire RunAs et les autorisations de répertoire. En supposant que vous ayez également accordé à votre ordinateur $ ou votre compte de domaine l'accès à cette base de données. Je doute que vous le fassiez, donc s'il utilise l'authentification normale par nom d'utilisateur / pwd, vous devriez pouvoir tout faire avec LocalService. Vous devez accorder un seul droit de compte sur ce répertoire, quel que soit celui que vous utilisez dans vos RunAs, pas les deux.
3.Je peux mal comprendre ce que fait le compte "Service réseau".
LocalService / NetworkService sont des comptes presque identiques sur l'ordinateur local. La différence réside principalement dans ce qu'ils peuvent faire sur le réseau. NS peut accéder à certaines ressources réseau car il apparaît sur le réseau en tant que compte réel (ordinateur). Mais LS apparaîtra comme ANONYME, donc tout ce qui se trouve sur le réseau sera refusé.
Soit dit en passant, vous devez utiliser une tâche planifiée pour cela, pas un service.
* À partir de Vista, en raison de l' isolement des services , un processus LocalService compromis ne peut pas facilement en attaquer un autre. Chaque processus / instance de service LocalService / NetworkService obtient son propre SID de session de connexion unique (propriétaire unique), contrairement à Windows 2003. Mais je ne suis pas sûr que ce soit parfait et atténue complètement la vulnérabilité DACL sur les fichiers et les ressources. Les SID et les jetons restreints en écriture sont mentionnés dans ce contexte.