La risposta precedente non sembrava rispondere direttamente alle domande, quindi ho pensato di aggiungere ad essa.
- Il mio piano è di eseguire il servizio come account "Servizio locale" predefinito. Ho intenzione di impostare esplicitamente i privilegi di "Controllo completo" per l'account "Servizio locale" sulla cartella che sto leggendo / scrivendo da e verso. Credo che quanto sopra sia un buon piano.
Personalmente, non vedo un grosso problema con questo piano. Con BUILTIN, la scelta è tra:
- Funzionando come LOCALSYSTEM - quindi se questo servizio è compromesso, l'attaccante possiede tutto e immediatamente.
- In esecuzione come LOCALSERVICE - quindi se questo servizio, o uno qualsiasi dei tanti altri servizi in esecuzione con questo account, sono compromessi, l'autore dell'attacco ha accesso a una directory aggiuntiva. *
Probabilmente, è preferibile aggiungere alcuni ACL aggiuntivi per poter utilizzare la seconda opzione. Sì, l'opzione più sicura per un servizio con privilegi bassi ma altamente sensibili alla sicurezza sarebbe quella di funzionare con un account di servizio personalizzato con privilegi limitati. Ma a meno che non si desideri creare un nuovo account / gestire le password per ogni servizio implementato, l'utilizzo di LocalService per attività secondarie non sensibili non è una cosa così terribile. Hai solo bisogno di prendere una decisione responsabile sulla base di queste considerazioni, come ciò che si trova in quella directory o quel database, impatto se vengono violati ecc.
Anche in questo caso, per principio del privilegio minimo, dovresti impostare solo Full Controlse non Modifyè davvero sufficiente.
2.La mia domanda è, per la cartella in cui sto leggendo e scrivendo, devo impostare un ruolo di "Servizio di rete" con accesso di controllo completo? Mi chiedo poiché il mio servizio utilizza la connettività del database a un altro server, se avrò bisogno della configurazione dell'account "Servizio di rete".
Se il tuo database richiede l'accesso a Windows Integrated / SSPI, quindi sì, dovrai utilizzare NetworkService (o un account del servizio di dominio) ovunque, ad esempio RunAs e autorizzazioni di directory. Supponendo che tu abbia anche concesso al tuo nomecomputer $ o all'account di dominio l'accesso a questo database. Dubito che lo stia facendo, quindi se utilizza la normale autenticazione username / pwd, dovresti essere in grado di fare tutto con LocalService. Devi concedere solo un diritto di account su quella directory, a prescindere da quello che usi nei RunAs, non entrambi.
3. Potrei fraintendere il comportamento dell'account "Servizio di rete".
LocalService / NetworkService sono account quasi identici sul computer locale. La differenza è principalmente ciò che possono fare sulla rete. NS può accedere ad alcune risorse di rete perché appare sulla rete come un account reale (computer). Ma LS apparirà come ANONIMO, quindi verrà negato per lo più tutto sulla rete.
A proposito, dovresti utilizzare un'attività pianificata per questo, non un servizio.
* Da Vista in poi, a causa dell'isolamento del servizio , un processo LocalService compromesso non può facilmente attaccarne un altro. Ogni processo / istanza del servizio LocalService / NetworkService ottiene la propria sessione di accesso unica SID (proprietario unico), a differenza di Windows 2003. Ma non sono sicuro che sia perfetto e mitiga completamente la vulnerabilità DACL su file e risorse. In questo contesto sono menzionati SID limitati e token con restrizioni di scrittura .