Windows - используйте локальную службу и / или учетную запись сетевой службы для службы Windows

NT AUTHORITY\NetworkServiceСчет нужен только тогда, когда вы общаетесь с другими компьютерами в домене, которые нуждаются в учетных данных вашего аппарата для контроля доступа. Это не требуется для простого доступа в Интернет / сеть. Это необходимо только для определенных целей в домене Active Directory.

Также весь смысл этой NT AUTHORITY\LocalServiceучетной записи в том, что она имеет минимальные привилегии в системе. Повышение привилегий снижает безопасность многих служб в вашей системе, предназначенных для работы на низком уровне привилегий, на который она была рассчитана. Если вашей службе требуются привилегии сверх этих, вы должны создать для нее новую учетную запись с необходимыми привилегиями и установить эту учетную запись на вкладке Вход в свойствах службы. (Это также может быть сделано программно.)

Вы также можете запустить его, используя NT AUTORITY\LocalSystemучетную запись, которая имеет неограниченный доступ к вашей системе, но я предполагаю, что вы хотели использовать эту LocalServiceучетную запись для повышенной безопасности, которую она обеспечивает.

Предыдущий ответ, похоже, не касался вопросов напрямую, поэтому я подумал, что добавлю к нему.

1. Мой план состоит в том, чтобы служба работала как учетная запись «Local Service» по умолчанию. Я собираюсь явно установить привилегии «Полный доступ» для учетной записи «Локальная служба» в папке, которую я читаю / записываю в и из. Я считаю, что вышесказанное - хороший план.

Лично я не вижу большой проблемы с этим планом. С BUILTINs, выбор между:

1. Запуск от имени LOCALSYSTEM - поэтому, если этот сервис скомпрометирован, злоумышленник владеет всем и сразу.
2. Запуск от имени LOCALSERVICE - поэтому, если эта служба или любая из множества других служб, работающих под этой учетной записью, скомпрометированы, злоумышленник получает доступ к одному дополнительному каталогу. *

Возможно, добавление нескольких дополнительных ACL для возможности использования второго варианта является предпочтительным. Да, самым безопасным вариантом для службы с низким уровнем привилегий, но с высокой степенью защиты, будет запуск под настраиваемой учетной записью с низким уровнем привилегий. Но если вы не хотите создавать новую учетную запись / управлять паролями для каждой развертываемой службы, использование LocalService для незначительных, не чувствительных задач не такая уж страшная вещь. Вам просто нужно принять ответственное решение на основе этих соображений, таких как, что находится в этом каталоге или этой базе данных, влияние, если они нарушены и т. Д.

Хотя опять же, по принципу наименьших привилегий, вы должны устанавливать только, Full Controlесли этого Modifyдействительно недостаточно.

2.Мой вопрос, для папки, в которую я читаю и пишу, нужно ли мне устанавливать роль «Сетевая служба» с полным доступом к управлению? Мне интересно, так как мой сервис использует подключение базы данных к другому серверу, если мне понадобится настройка учетной записи «Сетевой сервис».

Если для вашей базы данных требуется вход в систему Windows Integrated / SSPI, то да, вам нужно везде использовать NetworkService (или учетную запись службы домена), то есть RunAs и разрешения для каталога. Предполагая, что вы также предоставили доступ к этой базе данных своему имени компьютера или учетной записи домена. Я сомневаюсь, что вы делаете это, поэтому, если он использует обычную аутентификацию по имени пользователя / pwd, вы сможете делать все с помощью LocalService. Вам нужно предоставить только одну учетную запись для этого каталога, независимо от того, что вы используете в своих RunAs, а не оба.

3. Я могу неправильно понять, что делает учетная запись «Сетевой сервис».

LocalService / NetworkService - это практически идентичные учетные записи на локальном компьютере. Разница в основном в том, что они могут делать в сети. NS может получить доступ к некоторым сетевым ресурсам, потому что он отображается в сети как реальная (компьютерная) учетная запись. Но LS будет отображаться как ANONYMOUS, поэтому ему будет отказано в основном всему, что есть в сети.

Кстати, для этого вы должны использовать запланированное задание, а не сервис.

* Начиная с Vista, из-за изоляции сервисов один скомпрометированный процесс LocalService не может легко атаковать другой. Каждый процесс / экземпляр службы LocalService / NetworkService получает свой уникальный SID сеанса входа в систему (уникальный владелец), в отличие от Windows 2003. Но я не уверен, что это идеально и полностью устраняет уязвимость DACL для файлов и ресурсов. В этом контексте упоминаются SID с ограниченным доступом и токены с ограничением записи .

Другие ответы подтверждают, что вы говорите об использовании Local Service. Таким образом, локальная служба является рекомендуемой учетной записью для использования с вашей службой, если вам не нужны дополнительные функции Active Directory SSPI сетевой службы.

Для ограничения доступа на чтение / запись к определенной папке вы можете сделать лучше, чем просто предоставить доступ к общей учетной записи локальной службы. Проблема, как указывали другие, заключается в том, что это также предоставит доступ на чтение / запись ко всем другим службам, работающим как локальная служба, и если все службы сделают это, то постепенно локальная служба получит доступ ко все более важным ресурсам.

Решение состоит в том, чтобы вместо этого ACL вашу папку, используя ваш специальный SID службы. С вашим сервисным SID связан только ваш собственный сервисный процесс, поэтому это еще больше блокирует ваш ресурс. Вы можете просмотреть SID службы, используя sc showsid <service name>. SID службы генерируется из имени службы, поэтому он будет одинаковым на всех машинах.

Чтобы включить использование SID службы вашей службы, использовать ChangeServiceConfig2с SERVICE_SID_INFOструктурой для установки SERVICE_SID_TYPE_UNRESTRICTED. Вы также можете настроить SERVICE_SID_TYPE_RESTRICTEDполучение еще более ограниченного SID, который разрешает доступ на запись только к ресурсам, явно разрешенным с вашим SID службы.

Эта ссылка содержит высокоуровневые описания идентификаторов SID служб и идентификаторов SID с ограниченным доступом: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and- 2008 / hh125927 (v = ws.10)