Poprzednia odpowiedź nie wydawała się bezpośrednio dotyczyć pytań, więc pomyślałem, że ją uzupełnię.
- Moim planem jest uruchomienie usługi jako domyślnego konta „Usługa lokalna”. Zamierzam jawnie ustawić uprawnienia „Pełna kontrola” dla konta „Usługa lokalna” w folderze, z którego czytam / piszę do iz. Uważam, że powyższe jest dobrym planem.
Osobiście nie widzę dużego problemu z tym planem. W przypadku BUILTIN, wybór jest pomiędzy:
- Działa jako LOCALSYSTEM - więc jeśli ta usługa zostanie naruszona, atakujący jest właścicielem wszystkiego i natychmiast.
- Działa jako LOCALSERVICE - jeśli więc ta usługa lub dowolna z wielu innych usług działających na tym koncie zostanie naruszona, osoba atakująca ma dostęp do jednego dodatkowego katalogu. *
Prawdopodobnie lepiej jest dodać kilka dodatkowych list ACL, aby móc korzystać z drugiej opcji. Tak, najbezpieczniejszą opcją dla usługi o niskim poziomie uprawnień, ale o wysokim poziomie bezpieczeństwa jest uruchomienie niestandardowego konta usługi o niskim poziomie uprawnień. Ale chyba, że chcesz utworzyć nowe konto / zarządzać hasłami dla każdej wdrażanej usługi, użycie LocalService do drobnych niewrażliwych zadań nie jest tak straszną rzeczą. Musisz tylko podjąć odpowiedzialną decyzję w oparciu o te względy, takie jak zawartość tego katalogu lub bazy danych, wpływ, jeśli zostaną naruszone itp.
Chociaż znowu, zasada najmniejszych uprawnień, powinieneś ustawiać tylko Full Control
wtedy, gdy Modify
naprawdę nie jest wystarczająca.
2.Moje pytanie dotyczy folderu, do którego czytam i piszę, czy muszę skonfigurować rolę usługi sieciowej z pełnym dostępem kontrolnym? Zastanawiam się, ponieważ moja usługa korzysta z połączenia bazy danych z innym serwerem, czy będę potrzebować konfiguracji konta „Usługa sieciowa”.
Jeśli twoja baza danych wymaga logowania do Windows Integrated / SSPI, to tak, musisz używać NetworkService (lub konta usługi domeny) wszędzie, tj. RunAs i uprawnienia do katalogu. Zakładając, że przyznałeś również swojej nazwie komputera $ lub konto domeny dostęp do tej bazy danych. Wątpię, czy to robisz, więc jeśli używasz normalnego uwierzytelniania nazwy użytkownika / pwd, powinieneś być w stanie zrobić wszystko z LocalService. Musisz przyznać tylko jedno prawo do konta w tym katalogu, w zależności od tego, którego używasz w RunA, a nie oba.
3.Mógłbym nie rozumieć, co robi konto „Usługa sieciowa”.
LocalService / NetworkService to prawie identyczne konta na komputerze lokalnym. Różnica polega głównie na tym, co mogą zrobić w sieci. NS może uzyskać dostęp do niektórych zasobów sieciowych, ponieważ pojawia się w sieci jako rzeczywiste konto (komputerowe). Ale LS pojawi się jako ANONIMOWY, więc odmówi się głównie wszystkiego w sieci.
Nawiasem mówiąc, powinieneś używać do tego Zaplanowanego Zadania, a nie usługi.
* Począwszy od Visty, ze względu na izolację usług , jeden zaatakowany proces LocalService nie może łatwo zaatakować innego. Każdy proces / instancja usługi LocalService / NetworkService otrzymuje swój unikalny identyfikator SID sesji (unikalny właściciel), w przeciwieństwie do systemu Windows 2003. Nie jestem jednak pewien, czy jest to doskonały sposób i całkowicie eliminuje lukę DACL w plikach i zasobach. W tym kontekście wspomniane są ograniczone identyfikatory SID i tokeny z ograniczeniem zapisu .