14

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

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

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

3 ответа3

15

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

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

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

2

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

  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 получает свой собственный уникальный идентификатор безопасности сеанса входа в систему (уникальный владелец), в отличие от Windows 2003. Но я не уверен, что это идеально и полностью устраняет уязвимость DACL для файлов и ресурсов. В этом контексте упоминаются SID с ограниченным доступом и токены с ограничением записи .

1

Другие ответы подтверждают, что вы говорите об использовании 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)

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .