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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

Предыдущий ответ, по-видимому, не отвечал на вопросы напрямую, поэтому я решил его дополнить.

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

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

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

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

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

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

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

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

LocalService/Сетевой сервиспочти идентичные учетные записи на локальном компьютере. Разница в основном в том, что они могут делать в сети. NS может получить доступ к некоторым сетевым ресурсам, поскольку он отображается в сети как реальный (компьютерный) аккаунт. Но LS будет отображаться как АНОНИМНЫЙ, поэтому ему будет отказано практически во всем в сети.

Кстати, для этого вам следует использовать запланированную задачу, а не службу.

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