A resposta anterior não pareceu abordar as perguntas diretamente, então pensei em adicioná-la.
- Meu plano é que o serviço seja executado como a conta "Serviço local" padrão. Vou definir explicitamente privilégios de "Controle total" para a conta "Serviço local" na pasta na qual estou lendo / gravando. Eu acredito que o acima é um bom plano.
Pessoalmente, não vejo um grande problema com este plano. Com BUILTINs, a escolha é entre:
- Executando como LOCALSYSTEM - portanto, se esse serviço for comprometido, o invasor será o proprietário de Tudo e imediatamente.
- Executando como LOCALSERVICE - portanto, se este serviço, ou qualquer um dos muitos outros serviços executados sob esta conta, estiver comprometido, o invasor terá acesso a um diretório extra. *
Sem dúvida, é preferível adicionar algumas ACLs extras para poder usar a segunda opção. Sim, a opção mais segura para um serviço de baixo privilégio, mas altamente sensível à segurança, seria executada em uma conta de serviço personalizada e de baixo privilégio. Mas, a menos que você deseje criar uma nova conta / gerenciar senhas para cada serviço implantado, usar o LocalService para tarefas menores não sensíveis não é uma coisa tão terrível. Você só precisa tomar uma decisão responsável com base nessas considerações, como o conteúdo desse diretório ou banco de dados, o impacto se elas forem violadas, etc.
Embora, novamente, de acordo com o princípio do menos privilégio, você só deva definir Full Control
se Modify
não for realmente suficiente.
2. Minha pergunta é: para a pasta em que estou lendo e gravando, preciso configurar uma função "Serviço de Rede" com acesso total ao controle? Estou pensando em como meu serviço usa conectividade de banco de dados com outro servidor, se vou precisar da configuração da conta "Serviço de Rede".
Se seu banco de dados exigisse login no Windows Integrated / SSPI, sim, você precisaria usar o NetworkService (ou uma conta de serviço de domínio) em qualquer lugar, como RunAs e permissões de diretório. Supondo que você também concedeu ao seu nome de computador $ ou acesso à conta de domínio esse banco de dados. Duvido que você esteja fazendo isso, portanto, se ele usa autenticação normal por nome de usuário / senha, você deve poder fazer tudo com o LocalService. Você precisa conceder apenas um direito de conta nesse diretório, o que você usa nos seus RunAs, não ambos.
3.Pode estar entendendo mal o que a conta "Serviço de Rede" faz.
LocalService / 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 eles aparecem na rede como uma conta real (computador). Mas o LS aparecerá como ANÔNIMO; portanto, será negado principalmente tudo na rede.
A propósito, você deve usar uma Tarefa agendada para isso, não um serviço.
* A partir do Vista, devido ao isolamento do serviço , um processo LocalService comprometido não pode facilmente atacar outro. Cada processo / instância de serviço LocalService / NetworkService obtém sua própria SID de sessão de logon exclusiva (proprietário exclusivo), diferente do Windows 2003. Mas não tenho certeza se isso é perfeito e atenua totalmente a vulnerabilidade DACL em arquivos e recursos. SIDs restritos e tokens restritos à gravação são mencionados neste contexto.