Прямой ответ
Эти типы идентичности представляют разных участников, жизненные циклы и риски. Человеческая учётная запись принадлежит человеку; служебная — нечеловеческой рабочей нагрузке; субъект-служба представляет экземпляр приложения; управляемая идентичность является идентичностью рабочей нагрузки под управлением облачного поставщика; идентичность ИИ-агента принадлежит агенту, чьи цель, спонсор, инструменты и действия отслеживаются отдельно.
Простыми словами
На рабочем месте пропуск сотрудника, учётные данные автоматической двери и идентичность робота-доставщика не должны быть одним пропуском. Каждого участника нужно распознавать отдельно, чтобы выдать правильные разрешения и верно отнести действия.
Почему это важно
Автоматизация через человеческую учётную запись скрывает ответственность, переносит избыточные полномочия и может перестать работать после ухода человека. Одно имя модели также не показывает, какой экземпляр агента выполнил действие.
Не путать
- Идентичность, средство аутентификации и разрешение — разные вещи.
- Объект приложения и субъект-служба — разные объекты.
- Управляемая идентичность является управляемой формой идентичности, но её связь с использующим ресурсом всё равно нужно отслеживать.
- ИИ-агент не является самой базовой моделью.
Что делать
- Используйте отдельную идентичность для каждой рабочей нагрузки и каждого агента с серьёзными последствиями.
- Не запускайте фоновую автоматизацию через человеческую учётную запись.
- Свяжите каждую идентичность с целью, владельцем или спонсором, средой и жизненным циклом.
- Где возможно, предпочитайте краткоживущие или управляемые учётные данные долгоживущим статическим секретам.
- Записывайте идентичности инструмента, модели, среды выполнения и агента отдельно.
- Применяйте минимальные привилегии и регулярно проверяйте доступ.
Как проверить
- Правильно ли классифицирована идентичность?
- Не использует ли нечеловеческая нагрузка человеческую учётную запись?
- Актуален ли владелец или спонсор?
- Не используется ли без необходимости статический ключ?
- Прослеживаются ли связи агента, модели, инструментов и среды выполнения?
- Закрываются ли вместе с идентичностью её разрешения и секреты?
Ограничение
Терминология поставщиков различается. NOMOS предлагает общий словарь аудита, но не сводит модели идентичности Microsoft, Google и AWS к одной технической схеме.
Запомните одной фразой
Если человек, приложение, рабочая нагрузка и агент используют одну идентичность, установить исполнителя трудно.
Источники этой записи
- S24NIST SP 800-63-4, *Digital Identity Guidelines*Стандарты
- S25NIST SP 800-63B-4, *Authentication and Authenticator Management*Стандарты
- S29Microsoft Learn, *Application and Service Principal Objects in Microsoft Entra ID*Документация поставщика
- S30Microsoft Learn, *Managed Identities for Azure Resources*Документация поставщика
- S31Google Cloud, *Identities for Workloads*Документация поставщика
- S32AWS IAM, *Temporary Credentials with AWS Resources*Документация поставщика

