Учетные записи служб Microsoft являются важной частью любой экосистемы Windows, поскольку они используются для запуска основных служб и приложений, от веб-серверов до агентов транспортировки почты и баз данных. Но слишком часто они не используются и не управляются должным образом, что подвергает организацию ненужному риску сбоев в работе, нарушений протоколов безопасности и несоблюдения нормативных требований. Действительно, проблемы с учетными записями служб являются одной из четырех основных проблем, которые в основном выявляются во время анализа ИТ-безопасности.

Сегодня мы расскажем о 10 лучших способах эффекивно работать с учетными записями.

Учетные записи служб Microsoft — что это? 

Учетная запись службы Microsoft — это учетная запись, используемая для запуска одной или нескольких служб или приложений в среде Windows. Например, Exchange, SharePoint, SQL Server и Internet Information Services (IIS) работают под учетными записями служб. Учетная запись службы обеспечивает контекст безопасности для службы — другими словами, она определяет, к каким локальным и сетевым ресурсам служба может получить доступ и что она может делать с этими ресурсами. Учетные записи служб могут существовать на рабочих станциях, рядовых серверах и контроллерах домена (DC).

Существует несколько типов учетных записей служб Майкрософт, каждый из которых имеет свои преимущества и недостатки:

• Встроенная учетная запись службы. На локальном компьютере можно настроить запуск приложения под одной из трех встроенных учетных записей службы: LocalService, NetworkService или LocalSystem. Эти учетные записи не имеют паролей.
• Традиционная учетная запись службы. Традиционная учетная запись службы Майкрософт — это просто стандартная учетная запись пользователя. В идеале это должна быть учетная запись, созданная и используемая исключительно для запуска определенной службы, но слишком часто бизнес-пользователи и администраторы используют свои обычные учетные записи пользователей в качестве учетных записей служб во имя целесообразности. В отличие от встроенных учетных записей служб, эти учетные записи имеют пароли. Однако управление паролями сотен или тысяч учетных записей служб может очень быстро усложниться, а изменение пароля учетной записи службы создает риск взлома приложений или служб, для которых она используется. Поэтому многие организации устанавливают для своих паролей служебных учетных записей бесконечный срок действия и никогда не обновляют их, что ненамного лучше, чем полное отсутствие пароля. Традиционные служебные учетные записи можно создавать так же, как и любые другие учетные записи пользователей, например, в Active Directory Users and Computers ( ADUC) или ваше решение для управления идентификацией.
• Управляемая учетная запись службы (MSA) или, точнее, автономная управляемая учетная запись службы (sMSA). В Windows Server 2008 R2 Microsoft представила управляемую учетную запись службы, которая повышает безопасность, устраняя необходимость для администратора вручную управлять учетными данными для каждой службы. учетная запись. Вместо этого sMSA устанавливает сложный пароль и регулярно меняет этот пароль (по умолчанию каждые 30 дней). sMSA не может использоваться совместно несколькими компьютерами (отсюда и модификатор «автономный»).
• Групповая управляемая учетная запись службы (gMSA) — sMSA заменена групповой управляемой учетной записью службы. gMSA предоставляет те же функции, что и sMSA, но может использоваться на нескольких серверах и может использоваться для запуска запланированных задач. GMSA можно настроить и администрировать только на компьютерах под управлением Windows Server 2012 или более поздней версии, но их можно развернуть в доменах, в которых все еще есть контроллеры домена с более ранними операционными системами. Требования к функциональному уровню домена или леса отсутствуют. Чтобы создать gMSA, используйте командлет PowerShell New-ADServiceAccount. (Обязательно установите желаемый интервал смены пароля, потому что вы не сможете изменить его позже!) Новый gMSA будет расположен в контейнере Managed Service Accounts. Затем установите gMSA на хост с помощью Install-ADServiceAccount. Дополнительные сведения см. в пошаговом руководстве Microsoft.
• Учетная запись виртуальной службы. Как и sMSA, виртуальные учетные записи были представлены в Windows Server 2008 R2. Вы не можете вручную создать или удалить виртуальную учетную запись; он создается автоматически при установке службы с именем в формате NT SERVICE\<SERVICENAME>. Служба, работающая под виртуальной учетной записью, будет получать доступ к сетевым ресурсам, используя учетные данные учетной записи компьютера в формате <имя_домена>\<имя_компьютера>$.

10 лучших практик по созданию, использованию и управлению учетными записями служб Майкрософт

1. Знайте, какие учетные записи служб у вас есть и для чего они используются.

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

К сожалению, эта задача гораздо сложнее, чем может показаться на первый взгляд. Как отмечалось ранее, учетные записи служб Microsoft могут существовать на рабочих станциях, рядовых серверах и контроллерах домена, и существует множество различных типов учетных записей, которые можно использовать в качестве учетных записей служб, включая учетные записи обычных пользователей. С собственными инструментами вам нужно выйти на каждую из разных машин и выяснить, как на ней настроены приложения и службы. Очевидно, что делать это вручную нецелесообразно. Поэтому вам нужно автоматизировать сканирование, написав сценарий с помощью командлета Get-ADServiceAccount PowerShell или используя комплексное решение для отчетов о безопасности предприятия.

2. Не позволяйте администраторам использовать свои личные учетные записи в качестве служебных учетных записей.

Администраторы иногда используют свою учетную запись пользователя в качестве учетной записи службы. Это может показаться достаточно удобным. Что может пойти не так?

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

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

3. Для каждой службы используйте учетную запись службы Microsoft, предназначенную для этой службы.

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

Ответственность и устранение неполадок также становится намного сложнее. Например, если пароль для общей учетной записи службы изменен, каждая попытка приложения пройти аутентификацию с использованием старого пароля будет неудачной; вы увидите, что приложения не работают, но определить основную причину может быть непросто. Более того, если общая учетная запись службы будет удалена или ее пароль будет изменен, у вас будет отключена не одна служба, а множество, что усугубит влияние на бизнес.

Чтобы обеспечить соблюдение этой передовой практики, регулярно используйте решение, такое как Enterprise Reporter, для сканирования всех ваших компьютеров и создания отчета о том, какие учетные записи используются в качестве службы. Если несколько служб совместно используют учетную запись службы Microsoft, вы можете правильно настроить каждую службу с помощью выделенной учетной записи.

4. Строго соблюдайте минимальные привилегии.

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

Имейте в виду, что поставщики часто говорят, что их приложения требуют прав администратора домена, но на самом деле это не всегда так. Часто этот уровень привилегий требуется только для первоначальной установки службы, а не для ее последующего запуска. Предоставляя каждой учетной записи службы только те разрешения, которые ей действительно необходимы (так же, как и для любой другой учетной записи), вы ограничиваете ущерб, который вы можете понести, если учетная запись будет скомпрометирована, приложение взломано или имеет серьезную программную ошибку.

5. Оценивайте необходимость интерактивного входа в систему для сервисных учетных записей

Обратите особое внимание на то, должна ли служба иметь возможность входа в систему в интерактивном режиме. Интерактивный вход в систему обычно ограничен отдельными лицами, которым необходимо взаимодействовать с ИТ-средой путем создания документа, обмена сообщениями с товарищем по команде, создания заявки в службу поддержки и т. д. Учетные записи служб, с другой стороны, обычно запускают службы за кулисами, без необходимости такого взаимодействия. Действительно, некоторые эксперты советуют относиться к сервисным учетным записям, выполняющим интерактивный вход, как к тревожному сигналу. Один из способов применить эту передовую практику — поместить все учетные записи служб Microsoft в специальную группу безопасности AD и использовать групповую политику, чтобы предотвратить интерактивный вход любой учетной записи в этой группе.

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

6. По возможности используйте MSA.

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

7. Если вы не можете использовать MSA, обязательно измените пароли сервисных учетных записей регулярно.

Если приложение не поддерживает MSA, вам потребуется использовать обычную учетную запись службы Microsoft. В этом случае обязательно избегайте нескольких распространенных ошибок:

• Никогда не оставляйте для учетной записи службы пароль по умолчанию, выбранный поставщиком приложения. Хакеры могут легко найти эти пароли в Интернете и проникнуть в вашу сеть.
• Не выбирайте простые пароли. Фразы «1234» или «пароль» легко ввести, но невероятно легко взломать.
• Не устанавливайте бессрочный пароль. Слишком часто организации годами оставляют пароли сервисных учетных записей неизменными, что значительно увеличивает риск неправомерного использования или компрометации учетной записи.

Вместо этого выберите очень сложный пароль для каждой учетной записи службы и убедитесь, что он постоянно меняется. Рассмотрите возможность инвестирования в решение для управления привилегированными учетными записями (PAM), которое может управлять учетными данными для вас; таким образом, ни один человек никогда не узнает, что такое пароль, и его можно будет автоматически изменить.

8. Убедитесь, что вы можете быстро восстановить учетную запись службы или ее пароль.

Конечно, изменение пароля для учетной записи службы Microsoft сопряжено с риском: если изменение не будет выполнено должным образом, приложение или служба, с которыми оно связано, больше не смогут функционировать. Кроме того, может быть удалена сама учетная запись службы — например, она может быть удалена во время плановой очистки учетной записи или, как упоминалось выше, в рамках обычной деинициализации, когда администратор покидает организацию, но его учетная запись используется в качестве сервисного аккаунта.

Если это произойдет, критически важные бизнес-процессы могут быть легко нарушены, а часы тикают. Поэтому рекомендуется убедиться, что вы можете быстро восстановить любую учетную запись службы Microsoft, которая была удалена по ошибке, а также выборочно восстановить свойства учетной записи, такие как пароли, инвестируя в комплексное решение для резервного копирования и восстановления Active Directory.

9. Всегда ограничивайте делегирование учетных записей служб.

Учетную запись службы Майкрософт можно настроить таким образом, чтобы ей разрешался доступ к ресурсам от имени пользователя без необходимости входа в систему от имени этого другого пользователя. Например, предположим, что у вас есть веб-сервер, которому требуется доступ к данным в базе данных SQL Server. Вероятно, вы не хотите предоставлять учетной записи службы, которая запускает веб-сервер, разрешения на прямой доступ к базе данных; используя делегирование, вы можете включить его для запроса этих ресурсов от имени пользователя, который вошел в систему, используя свои собственные учетные данные.

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

Чтобы ограничить делегирование учетной записи службы Microsoft, откройте «Пользователи и компьютеры Active Directory», перейдите к «Просмотр» и включите «Дополнительные функции». Щелкните правой кнопкой мыши учетную запись службы и выберите Делегирование. Затем выберите «Доверять этому пользователю делегирование только указанным службам» и выберите соответствующие службы в поле ниже. Также разумно разрешить использование только протокола Kerberos, так как это самый безопасный протокол аутентификации. (Обратите внимание, что для использования проверки подлинности Kerberos учетная запись службы должна иметь имя участника-службы (SPN), зарегистрированное в Active Directory.)

10. Очистите учетные записи, которые больше не нужны.

Разрастание числа сервисных учетных записей — это тоже то, о чем вам нужно беспокоиться. В конце концов, ваша ИТ-среда — это очень динамичное место, где программные решения постоянно заменяются новыми и лучшими технологиями. Но когда службы или приложения выводятся из эксплуатации, связанные учетные записи служб часто не очищаются. Эти учетные записи не безобидны: они загромождают ваш каталог и мешают вам оставаться на вершине разрешений, и они представляют собой проблему безопасности, поскольку хакер может захватить их и использовать, чтобы закрепиться в вашей среде (особенно если вы не были строги в обеспечении наименьших привилегий).

Поэтому важно регулярно проверять свои учетные записи служб Microsoft и выявлять те, которые не используются. Такое решение, как Enterprise Reporter, упрощает работу; вы можете просто запланировать запуск отчета по желаемому расписанию и проверить учетные записи служб, которые больше не активны. Если дальнейшее расследование покажет, что конкретная учетная запись действительно больше не нужна, вы можете деактивировать или удалить ее или использовать в качестве ловушки для хакеров. Чтобы удалить управляемую учетную запись службы, используйте командлет Remove-ADServiceAccount.

Остались вопросы?

Учетные записи служб Майкрософт являются неотъемлемой частью вашей ИТ-экосистемы. Поскольку они обычно имеют повышенные разрешения, очень важно правильно ими управлять. Следование приведенным рекомендациям поможет вам избежать инцидентов, связанных с безопасностью, сбоев в работе и несоблюдения нормативных требований.

Мы в Fanetech будем рады ответить на любые вопросы. Просто свяжитесь с нами.