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

Каковы лучшие практики для учетных записей служб?

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

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

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

Несколько мыслей:

  • Одна учетная запись для каждой службы или, возможно, для каждого типа службы в зависимости от вашей среды.

  • Учетные записи должны быть учетными записями домена.

  • У учетных записей должен быть надежный пароль, срок действия которого не истекает *. В идеале создайте случайный пароль, который где-то записывается (KeePass подходит для этого), чтобы людям было сложно использовать его для входа в систему. Говоря о которых...

  • ... (Как правило) учетная запись должна быть членом группы, у которой нет прав на интерактивный вход. Это можно контролировать с помощью групповой политики.

  • Помните о принципе наименьших привилегий. Аккаунты должны иметь права, необходимые для выполнения своей работы и не более. В соответствии с этим, как указывает gravyface, по возможности используйте встроенные учетные записи. Local Service когда доступ к сети не требуется. Network Service при доступе к сети, поскольку учетная запись машины будет достаточно безопасной, и избегайте использования Local System аккаунт, где это возможно.

* Если политика безопасности вашей компании не совместима с этим, но, судя по всему, это, вероятно, так :-)