A resposta anterior não pareceu abordar as perguntas diretamente, então eu pensei em adicionar isso.
- My plan is to have the service run as the default "Local Service" account. I'm going to explicitly set "Full Control" privileges for the
"Local Service" account on the folder that I'm reading/writing to and
from. I believe the above is a good plan.
Pessoalmente, não vejo grande problema com esse plano. Com BUILTINs, a escolha é entre:
- Executando como LOCALSYSTEM - portanto, se esse serviço for comprometido, o invasor
possui Tudo , e imediatamente.
- Executando como LOCALSERVICE - portanto, se esse serviço ou qualquer um dos muitos outros serviços executados nessa conta forem comprometidos, o invasor terá acesso a um diretório extra. *
Indiscutivelmente, adicionar algumas ACLs extras para poder usar a segunda opção é preferível. Sim, a opção mais segura para um serviço de baixo privilégio, mas altamente sensível à segurança, seria executar sob uma conta de serviço de baixo privilégio personalizada. Mas, a menos que você queira criar uma nova conta / gerenciar senhas para todos os serviços implantados, o uso de LocalService para pequenas tarefas não sensíveis não é algo tão terrível. Você só precisa tomar uma decisão responsável com base nessas considerações, como o que está nesse diretório ou no banco de dados, se elas forem violadas, etc.
Embora novamente, pelo princípio de privilégio, você deve definir apenas Full Control se Modify não for realmente suficiente.
2.My question is, for the folder that I'm reading and writing to, do I need to setup a "Network Service" role with full control access? I'm
wondering since my service uses database connectivity to another
server, if I'll need the "Network Service" account setup.
Se o seu banco de dados exigisse login do Windows Integrated / SSPI, então sim, você precisaria usar NetworkService (ou uma conta de serviço de domínio) em todos os lugares, ou seja, permissões RunAs e de diretório. Supondo que você também concedeu ao seu nome de computador $ ou acesso à conta de domínio a este banco de dados.
Eu duvido que você esteja fazendo isso, então se ele usa autenticação normal por username / pwd, você deve poder fazer tudo com o LocalService. Você precisa conceder apenas um direito de conta nesse diretório, o que você usa em seus RunAs, não em ambos.
3.I may be misunderstanding what the "Network Service" account does.
Serviço local / NetworkService são contas quase idênticas no computador local. A diferença é principalmente o que eles podem fazer na rede. O NS pode acessar alguns recursos de rede porque aparece na rede como uma conta real (computador). Mas o LS aparecerá como ANÔNIMO, então será negado quase tudo na rede.
A propósito, você deve estar usando uma tarefa agendada para isso, não um serviço.
* Do Vista em diante, devido ao isolamento de serviço , um processo LocalService comprometido não pode atacar facilmente outro. Cada processo / instância de serviço LocalService / NetworkService obtém seu próprio SID de sessão de logon exclusivo (proprietário exclusivo), diferente do Windows 2003. Mas não tenho certeza se isso é perfeito e atenua totalmente a vulnerabilidade de DACL em arquivos e recursos. SIDs restritos e tokens com restrição de gravação são mencionados neste contexto.