Назад | Перейти на главную страницу

Должны ли службы Windows создаваться с настраиваемыми пользователями или я должен использовать один из LocalSystem / LocalService / NetworkService

Я задаю вопрос в общем для средней пользовательской службы NT или unix-демона OSS, перенесенного на Windows с поддержкой SCM. Однако на данный момент меня беспокоят mongodb.

Исходя из моего опыта работы с UNIX, мне нравится, что все мои службы запускаются от имени разных непривилегированных пользователей. То, как это было переведено в окна, выглядит следующим образом:

  1. Создайте локального (или домена, если он должен разговаривать с SQL-сервером) пользователя Windows с длинным случайным паролем (в последнее время guid в кодировке ASCII85, сгенерированный на другой машине). Установите для него следующий срок действия и запретите ему изменять свой пароль.
  2. Удалите этого пользователя из «Группы пользователей». Предоставьте этому пользователю разрешение «Войти как услуга».
  3. Предоставьте ему разрешение на чтение папки, в которой находится приложение, и разрешение на запись в журналы и файлы данных, используемые приложениями.
  4. Назначьте пользователя сервису.
  5. Устраняйте неполадки, пока служба не запустится.

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

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

Кроме того, я дополнительно ограничиваю и предоставляю дополнительные права учетным записям домена с помощью Назначения прав пользователя в групповой политике:

Security Settings folder - Local Policies - User Rights Assignment

Вы также можете обнаружить, что для некоторых служб требуются права, назначенные их учетной записи службы в Active Directory, в этом случае я попытаюсь применить доступ с группами на основе ролей («Чтение учетной записи студента», «Чтение учетной записи персонала», «Запись учетной записи студента», и т. д.) и поместите учетную запись службы в эту группу.

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