Windows - Gunakan akun Layanan Lokal dan / atau Layanan Jaringan untuk layanan windows


18

Saya telah membuat layanan jendela yang memonitor file pada direktori tertentu pada OS Windows kami. Ketika file terdeteksi, layanan melakukan beberapa file I / O, membaca file, membuat sub-direktori, dll. Layanan ini juga menggunakan konektivitas database untuk terhubung ke server lain. Rencana saya adalah menjalankan layanan sebagai akun "Layanan Lokal" default. Karena saya perlu membolehkan hak istimewa untuk menulis / membaca, yang ternyata akun "Layanan Lokal" tidak dilakukan secara default, saya akan secara eksplisit menetapkan hak istimewa "Kontrol Penuh" untuk akun "Layanan Lokal" pada folder yang saya pilih. membaca / menulis ke dan dari.

Saya percaya hal di atas bagus. Pertanyaan saya adalah, untuk folder tempat saya membaca dan menulis, apakah saya perlu mengatur peran "Layanan Jaringan" dengan akses kontrol penuh? Saya ingin tahu karena layanan saya menggunakan konektivitas database ke server lain, apakah saya memerlukan pengaturan akun "Layanan Jaringan".

Saya mungkin salah paham tentang apa yang dilakukan akun "Layanan Jaringan".

Jawaban:


18

The NT AUTHORITY\NetworkServiceakun hanya diperlukan ketika Anda berkomunikasi dengan komputer lain dalam domain yang perlu mandat mesin Anda untuk kontrol akses. Tidak diperlukan untuk akses Internet / jaringan yang sederhana. Ini hanya diperlukan untuk tujuan khusus dalam domain Direktori Aktif.

Seluruh poin dari NT AUTHORITY\LocalServiceakun ini adalah bahwa ia memiliki hak minimum pada sistem. Memberikannya lebih istimewa mengurangi keamanan banyak layanan pada sistem Anda yang dirancang untuk berjalan pada tingkat privilege rendah yang dirancang untuk ditawarkan. Jika layanan Anda memerlukan hak istimewa di atas dan di luar itu, Anda harus membuat akun baru untuk itu dengan hak istimewa yang diperlukan dan mengatur akun itu di tab Masuk pada properti layanan. (Ini juga dapat dilakukan secara terprogram.)

Anda juga dapat menjalankannya menggunakan NT AUTORITY\LocalSystemakun , yang memiliki akses tidak terbatas ke sistem Anda, tetapi saya berasumsi Anda ingin menggunakan LocalServiceakun untuk meningkatkan keamanan yang disediakannya.


1
Bagaimana memberikan kendali penuh pada akun LocalService pada satu folder (dan sub-folder) mengurangi keamanan layanan lainnya?
contactmatt

1
@ user19185 Ini tidak mengurangi keamanan mereka sendiri , tetapi meningkatkan profil serangan. Jika suatu layanan berjalan seperti LocalServicedikompromikan, ia akan memiliki akses ke apa pun yang Anda buka LocalService, sedangkan biasanya ia tidak memiliki akses apa pun. Ini telah menjadi prosedur operasi keamanan komputer standar sejak tahun 70-an .
Tambalan

1
Hanya ingin menunjukkan bahwa LocalSystemmemiliki lebih banyak hak dan keistimewaan daripada akun adminstrator biasa.
Stein Åsmul

@Stein Åsmul: terima kasih atas koreksinya! Saya memperbarui jawaban saya untuk mencerminkan ini.
Tambalan

2

Jawaban sebelumnya tampaknya tidak menjawab pertanyaan secara langsung, jadi saya pikir saya akan menambahkannya.

  1. Rencana saya adalah menjalankan layanan sebagai akun "Layanan Lokal" default. Saya akan secara eksplisit menetapkan hak istimewa "Kontrol Penuh" untuk akun "Layanan Lokal" pada folder yang saya baca / tulis dari dan ke. Saya percaya hal di atas adalah rencana yang bagus.

Secara pribadi, saya tidak melihat masalah besar dengan rencana ini. Dengan BUILTIN, pilihannya adalah antara:

  1. Berjalan sebagai LOCALSYSTEM - jadi jika layanan ini dikompromikan, penyerang memiliki Semuanya , dan segera.
  2. Berjalan sebagai LOCALSERVICE - jadi jika layanan ini, atau salah satu dari banyak layanan lain yang berjalan di bawah akun ini, dikompromikan, penyerang memiliki akses ke satu direktori tambahan. *

Lebih disukai, menambahkan beberapa ACL tambahan untuk dapat menggunakan opsi kedua lebih disukai. Ya, opsi teraman untuk layanan dengan privilege rendah tetapi sangat peka terhadap keamanan akan dijalankan di bawah akun layanan khusus dengan privilege rendah. Tetapi kecuali jika Anda ingin membuat akun baru / mengelola kata sandi untuk setiap layanan yang Anda gunakan, menggunakan LocalService untuk tugas-tugas kecil yang tidak sensitif bukanlah hal yang mengerikan. Anda hanya perlu membuat keputusan yang bertanggung jawab berdasarkan pertimbangan-pertimbangan ini, seperti apa yang ada di direktori itu atau basis data itu, dampaknya jika dilanggar dll.

Meskipun sekali lagi, per prinsip privilege, Anda hanya boleh menetapkan Full Controljika Modifybenar-benar tidak memadai.

2. Pertanyaan saya adalah, untuk folder tempat saya membaca dan menulis, apakah saya perlu mengatur peran "Layanan Jaringan" dengan akses kontrol penuh? Saya ingin tahu karena layanan saya menggunakan konektivitas database ke server lain, apakah saya memerlukan pengaturan akun "Layanan Jaringan".

Jika database Anda memerlukan login Windows Integrated / SSPI, maka ya, Anda harus menggunakan NetworkService (atau akun layanan domain) di mana-mana, misalnya, RunA dan izin direktori. Dengan asumsi Anda juga memberikan $ komputer atau akun domain Anda akses ke database ini. Saya ragu Anda melakukan itu, jadi jika menggunakan otentikasi nama pengguna / pwd normal, Anda harus dapat melakukan semuanya dengan LocalService. Anda hanya perlu memberikan satu hak akun pada direktori itu, mana yang Anda gunakan dalam RunA Anda, tidak keduanya.

3. Saya mungkin salah paham tentang apa yang dilakukan akun "Layanan Jaringan".

LocalService / NetworkService adalah akun yang hampir identik di komputer lokal. Perbedaan utamanya adalah apa yang dapat mereka lakukan pada jaringan. NS dapat mengakses beberapa sumber daya jaringan karena muncul di jaringan sebagai akun (komputer) nyata. Tetapi LS akan muncul sebagai ANONYMOUS, jadi sebagian besar jaringan akan ditolak.

Omong-omong, Anda harus menggunakan Tugas Terjadwal untuk ini, bukan layanan.

* Dari Vista dan seterusnya, karena isolasi layanan , satu proses LocalService yang dikompromikan tidak dapat dengan mudah menyerang yang lain. Setiap proses layanan / instance LocalService / NetworkService mendapatkan sesi logon uniknya sendiri SID (pemilik unik), tidak seperti Windows 2003. Tapi saya tidak yakin ini sempurna dan sepenuhnya mengurangi kerentanan DACL pada file dan sumber daya. SID terbatas dan token terbatas tulis disebutkan dalam konteks ini.


2

Jawaban lain mengkonfirmasi apa yang Anda katakan tentang menggunakan Layanan Lokal. Untuk meringkas, Layanan Lokal adalah akun yang disarankan untuk digunakan dengan layanan Anda, kecuali jika Anda memerlukan fitur SSPI Direktori Aktif tambahan dari Layanan Jaringan.

Untuk membatasi akses baca / tulis ke folder tertentu, Anda dapat melakukan lebih baik daripada hanya memberikan akses ke akun Layanan Lokal umum. Masalahnya, seperti yang telah ditunjukkan oleh orang lain, adalah bahwa ini juga akan memberikan akses baca / tulis ke semua layanan lain yang berjalan sebagai Layanan Lokal dan jika semua layanan melakukan ini maka Layanan Lokal secara bertahap akan menerima akses ke sumber daya yang semakin penting.

Solusinya adalah dengan ACL folder Anda menggunakan SID layanan spesifik Anda. Hanya proses layanan Anda sendiri yang terkait dengan SID layanan Anda, jadi ini akan mengunci sumber daya Anda lebih jauh. Anda dapat melihat SID layanan menggunakan sc showsid <service name>. SID layanan dihasilkan dari nama layanan, sehingga sama pada semua mesin.

Untuk mengaktifkan layanan SID penggunaan oleh layanan Anda, gunakan ChangeServiceConfig2dengan SERVICE_SID_INFOstruktur untuk mengatur SERVICE_SID_TYPE_UNRESTRICTED. Anda juga dapat mengatur SERVICE_SID_TYPE_RESTRICTEDuntuk mendapatkan SID yang lebih terbatas yang hanya memungkinkan akses tulis ke sumber daya yang diizinkan secara eksplisit dengan SID layanan Anda.

Tautan ini memiliki deskripsi tingkat tinggi tentang SID layanan dan SID layanan terbatas: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and- 2008 / jj125927 (v = ws.10)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.