Почему ваши учётные записи «svc-» — это бомба замедленного действия

By Mirko Peters · 2026-08-11

Добро пожаловать обратно в подкаст и в наше продолжающееся глубокое погружение в архитектуру безопасности предприятия. Если ваша организация похожа на большинство, беглый взгляд на Active Directory или каталог Microsoft Entra ID покажет целое кладбище учётных записей, названия которых начинаются с «svc-», «app-» или «admin-bot». Эти учётные записи обеспечивают работу систем, поток данных и выполне

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

Добро пожаловать обратно в подкаст и в наш продолжающийся глубокий разбор архитектуры безопасности предприятия. Если в вашей организации, как и в большинстве, просмотреть Active Directory или каталог Microsoft Entra ID, вы найдёте разросшееся кладбище учётных записей с префиксами «svc-», «app-» или «admin-bot». Эти учётные записи поддерживают работу систем, обеспечивают движение данных и выполнение автоматизаций. Но они же являются самым большим слепым пятном в вашей современной защите. В этой статье мы развиваем нашу последнюю беседу и разбираем, почему традиционные учётные записи служб полностью подрывают вашу архитектуру Zero Trust и почему переход на Microsoft Entra Workload Identities — единственный правильный путь.

Полностью аудиоверсию этой темы можно послушать в нашем подкасте-компаньоне: Replace Service Accounts with Entra Workload Identities. А теперь давайте разберём механику нечеловеческих рисков и то, как устранить их раз и навсегда.

Коротко

Сервисные учётные записи со статическими секретами и широкими правами — ваш самый большой пробел в идентификации. Workload Identities (в Microsoft Entra ID) дают каждому нечеловеческому субъекту управляемую идентичность с принципом наименьших привилегий, жизненным циклом, политиками условного доступа, ротацией и полным журналом аудита — и без поломки ваших автоматизаций.

Почему сервисные учётные записи не работают (и ломают Zero Trust)

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

Статические секреты и отсутствие MFA → их легко украсть, и их сложно безопасно сменить
Избыточные права по умолчанию → разрешения, выданные по принципу «пусть работает», становятся постоянными
Нет жизненного цикла → забытые и осиротевшие учётные записи переживают миграции и реорганизации
Слабая аудируемость → вопрос «кто и зачем использовал эту запись?» превращается в гадание и скриншоты
Культура исключений → исключения для ботов из политик CA и MFA незаметно расширяют вашу поверхность атаки

Managed Identities: хороший шаг, но только в рамках Azure

Когда организации понимают, что статические сервисные учётные записи опасны, их первым естественным шагом часто становятся Azure Managed Identities. Managed Identities — большой шаг вперёд, поскольку они полностью устраняют секреты для ресурсов, размещённых в Azure, но у них есть явные границы.

✅ Доступ без секретов для нативных ресурсов Azure (Functions, VM, Logic Apps)
❌ Пробелы для гибридных и сторонних целевых систем, слабое сопоставление владельцев, ограниченные представления управления
❌ Покрытие CA и политик доступа неравномерно на поверхностях вне Azure

Workload Identities: что вы получаете на практике

Именно здесь на сцену выходят Microsoft Entra Workload Identities. Вместо того чтобы относиться к нечеловеческим субъектам как к гражданам второго сорта или загонять вас в ограничения, свойственные только Azure, Workload Identities возводят приложения, скрипты и автоматизированные сервисы в ранг полноценных субъектов безопасности.

Полноценные нечеловеческие идентичности (приложения, скрипты, коннекторы, RPA, интеграции)
Ограниченные разрешения (роли Graph и ресурсов, аутентификация только для приложений) с принципом наименьших привилегий
Жизненный цикл (владелец, частота проверок, процедура вывода из эксплуатации), привязанный к бизнес-процессу
Условный доступ для рабочих нагрузок (шлюзы с учётом риска и контекста, управление сеансами там, где это поддерживается)
Гигиена учётных данных (короткоживущие секреты, сертификаты, политика ротации ключей)
Единая видимость (входы, токены, доступ к ресурсам, история изменений) → готовность к аудиту

Сравнительная матрица (кратко)

Возможность	Сервисная учётная запись	Managed Identity	Workload Identity
Секреты	Статические пароли	Без секретов (Azure)	Без секретов или короткоживущие + ротация
Область применения	Широкая / как у пользователя	Ориентирована на Azure	Любая рабочая нагрузка (приложения, скрипты, коннекторы)
CA / риск	Применяется редко	Ограниченно	Управляется политиками там, где поддерживается
Жизненный цикл	Ad hoc	Базовый	Владелец + проверки + вывод из эксплуатации
Аудит	Фрагментарный	Журналы Azure	Централизованный журнал входов и назначенных разрешений

Архитектурные паттерны (типовые сценарии)

Внедрение рабочих идентичностей требует их корректного сопоставления с вашими архитектурными шаблонами. Вот как они применяются к наиболее распространённым корпоративным рабочим нагрузкам:

Коннекторы Power Platform / облачные потоки -> Назначьте рабочую идентичность для каждой интеграции; предоставляйте только необходимые области Graph/Dataverse.
Приложения для бизнеса (веб-API, демоны) -> регистрация приложения + сертификат; используйте роли приложений и Graph только для приложения; применяйте CA там, где это возможно.
Скрипты автоматизации (Azure Automation, GitHub Actions, DevOps) -> Используйте федеративные учётные данные (OIDC), без хранимых секретов.
Межклиентские / B2B-задачи -> Выделенная рабочая идентичность для каждой границы клиента; изолируйте права и журналирование.

Плейбук миграции (90 дней, без лишних потрясений)

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

Этап 1 — обнаружение и сортировка (недели 0–3)

Составьте инвентаризацию нечеловеческих входов и объектов: svc-*, app-*, общие почтовые ящики, регистрации приложений, секреты, срок действия которых истекает менее чем через 90 дней.
Сопоставьте каждый объект с владельцем, бизнес-назначением, целями, разрешениями и зависимостью от аварийных учётных записей.
Проранжируйте по риску: статичные пароли, глобальные роли, отсутствие владельца, отсутствие недавней ротации.

Этап 2 — сначала переводим высокорисковые (недели 4–8)

Создайте рабочую идентичность для каждой интеграции (не переиспользуйте).
Замените парольную аутентификацию на сертификаты или федеративные учётные данные; настройте ротацию.
Перейдите на разрешения только для приложения; удалите делегированные пользователем там, где они не нужны.
Примените политики условного доступа для входов рабочих нагрузок (где поддерживается).
Внедрите проверки доступа (ежеквартально) и владение в CMDB/ITSM.

Этап 3 — вывод из эксплуатации и управление (недели 9–12)

Отключите старые сервисные учётные записи; наблюдайте за ними 14 дней, затем удалите.
Внедрите стандарты создания: именование, владелец, классификация данных, периодичность проверок.
Настройте оповещения: аномальные входы, неактивные идентичности более 30/60/90 дней, истекающие секреты.
Встройте проверки идентичности в CI/CD (политика как код).

Условный доступ и разрешения (практические ограничения)

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

Отдельные политики для человеческих и рабочих идентичностей; блокируйте интерактивный вход для рабочих нагрузок.
Именованные расположения / сетевые ограничения для доступа только для приложения, где это возможно.
Ограниченные по времени права (PIM для ролей приложений, где доступно; запланированные проверки доступа).
Области действия: предпочитайте роли приложений / роли, ограниченные конкретным ресурсом, вместо прав на уровне всего каталога.

Журналирование и аудит (что показать аудитору)

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

Владелец приложения или рабочей нагрузки, назначение, чувствительность данных
Журналы входа (входы субъектов-служб), аудитория токена, IP-адрес, клиентское приложение
Назначения ролей (кто утвердил, когда прошла сертификация)
История учётных данных (тип, последняя ротация, срок действия)
Жизненный цикл: создано/изменено/отключено/удалено с указанием инициатора изменения

Панель KPI (докажите улучшение)

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

Доля нечеловеческих идентичностей с владельцем и периодичностью проверки (цель ≥ 95 %)
Осиротевшие сервисные учётные записи (цель -> 0)
Секреты старше 90 дней (цель -> 0; предпочтительно сертификаты/федеративные учётные данные)
Широта ролей только для приложения (количество «Directory.ReadWrite.All» -> тренд к снижению)
Результаты аудита доступа нечеловеческих субъектов (квартал к кварталу ↓)

Антишаблоны, которые нужно устранить

По мере очистки среды следите, чтобы команды не возвращались к старым привычкам. Немедленно искореняйте такие антишаблоны:

Повторное использование одной общей сервисной учётной записи во многих системах
Хранение паролей в скриптах, web.config или Key Vault без какой-либо политики ротации
Выдача Global Admin / Owner «на всякий случай», чтобы задания продолжали работать
«Временные» исключения из CA, которые никогда не истекают

Быстрые победы (на этой неделе)

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

Пометьте каждую нечеловеческую идентичность тегами Owner, System, Data Class.
Переведите одно высокорисковое задание на федеративные учетные данные (GitHub OIDC -> Entra).
Замените общую сервисную учетную запись в Power Automate на удостоверение рабочей нагрузки.
Создайте отчет по субъектам-службам с истекающими или истекшими секретами и настройте расписание оповещений.

Часто задаваемые вопросы (быстрые ответы)

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

Можно ли применять Conditional Access к входам нечеловеческих учетных записей?
Да, для поддерживаемых сценариев (входы субъектов-служб). Где применимо, используйте сигналы сети, местоположения и устройства, а интерактивные входы блокируйте.

Как не допустить разрастания количества учетных записей?
Одно удостоверение рабочей нагрузки на интеграцию (а не на команду). Обеспечьте соблюдение соглашения об именовании, владельца и проверок при создании; автоматизируйте очистку неактивных учетных записей.

А как быть с Power Platform?
Используйте субъекты-службы / удостоверения рабочих нагрузок для коннекторов и Dataverse; перестаньте использовать общие пользовательские учетные записи.

Заключение

От рисков сервисных учетных записей не спасти одной только ротацией паролей. Entra Workload Identities переводят доступ нечеловеческих учетных записей в ту же модель Zero Trust, жизненного цикла и аудита, которую вы уже требуете для людей, и делают это без простоев и героических усилий. Начните с самых рискованных учетных записей «svc-», переведите их на управляемые удостоверения рабочих нагрузок и снова сделайте исключения исключениями.

Если вам понравился этот материал, обязательно послушайте полное обсуждение в нашем подкасте: Replace Service Accounts with Entra Workload Identities. Подписывайтесь на шоу, чтобы получать больше подробных разборов стратегий безопасности корпоративных сред Microsoft 365 и Azure!