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

Я создал службу окна, которая отслеживает файлы в определенном каталоге в нашей ОС Windows. Когда файл обнаружен, служба выполняет некоторые операции ввода-вывода, считывает файлы, создает подкаталоги и т. Д. Эта служба также использует подключение к базе данных для подключения к другому серверу. Мой план состоит в том, чтобы служба работала как учетная запись «Local Service» по умолчанию. Так как мне нужно разрешить права на запись / чтение, которые, по-видимому, учетная запись «Local Service» по умолчанию не делает, я собираюсь явно установить привилегии «Full Control» для учетной записи «Local Service» в папке, которую я чтение / запись в и из.

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

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

Эта 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)