Перейти к содержимому

Машинный перевод. Авторитетным источником является английская версия; проверка носителем языка ещё не выполнена.

Продукт · Identity и NHI

Дайте каждому агенту собственную идентичность — и узнавайте, когда её нет

Общая сервисная учётная запись делает вопрос «какой агент это сделал?» безответным. Olivares привязывает агента к нечеловеческой идентичности, выпускает отдельную NHI для каждого агента и выявляет агентов, которые делят одну, — в этом и состоит разница между уверенной и лишь приблизительной атрибуцией доступа. Идентичность, которую система не может разрешить, никогда молча не выдаётся за настоящую.

В продукте

Консоль идентичностей

Настоящий скриншот, демонстрационные данные. Вкладки для SSO/SCIM, реестра NHI, аутентификации MCP, графа WIF, состояния ключей и резидентности данных, а также привилегированных входов. Снимок сделан до выхода серверной части SSO/SCIM, поэтому вкладка SSO/SCIM всё ещё показывает честное уведомление той сборки «серверная часть в ожидании» — настоящие экраны, никогда не сфабрикованные данные.

Реальный скриншот
Консоль идентичностей Olivares: вкладки для SSO/SCIM, реестра NHI, аутентификации MCP, графа WIF, состояния ключей и резидентности данных и привилегированных входов; на этом более раннем снимке вкладка SSO/SCIM показывает уведомление об ожидании серверной части вместо сфабрикованных данных.

Чем вы управляете

От общей учётной записи к идентичности на каждого агента

Идентичность — это ось, по которой карта доступа атрибутирует действия. Отдельная NHI для каждого агента превращает «приблизительно» в «уверенно»; всё, что ниже, честно говорит о том, как далеко система может зайти.

Привяжите или выпустите NHI

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

Выявление общей идентичности

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

Граф WIF только для чтения

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

Честное «неизвестно»

Идентичность, которую Olivares не может разрешить, изображается как неизвестная и помечается — её никогда молча не повышают до именованной NHI. Нет сигнала об идентичности — нет атрибуции, сказано прямо.

Как это работает

Федерация идентичности агента с вашим IdP

Каждый агент получает собственную идентичность — учётные данные SPIFFE/WIF, — которая федерируется с вашим поставщиком идентичности. Агент без разрешимой идентичности не объединяется с настоящей: он изображается отдельно и помечается.

Схема: агенты сопоставляются с идентичностью на каждого агента (SPIFFE/WIF), которая федерируется с Entra ID, AWS IAM и Google Cloud; у одного агента нет идентичности, и он изображён пунктиром и помечен «нет идентичности».
Неизвестный агент изображён пунктиром и помечен «нет идентичности» — его никогда не объединяют с настоящей NHI. Показанная федерация отражает объявленные вами правила.

Что реально

Привязка NHI, аппаратное повышение уровня и SSO/SCIM работают; живая проверенная федерация — нет

Мы точны в этом, потому что именно эта разница и есть весь смысл поверхности идентичности:

  • Работает: привязка агента к NHI, выпуск отдельной NHI для каждого агента, выявление общей идентичности и граф WIF только для чтения. Граф отражает объявленные вами правила федерации — это не картина федерации, проверенная вживую на канале.
  • Поставлено как чтение без записи: коннекторы ростеров читают реестры идентичностей агентов гиперскейлеров — Microsoft Entra Agent ID, AWS Bedrock AgentCore и реестр агентов Google. Живая проверенная федерация на канале с этими реестрами остаётся в планах, и мы не заявляем о ней, пока она не выйдет.
  • Поставлено для людей: повышение уровня через WebAuthn/FIDO2 и смарт-карту PIV/CAC для привилегированных входов, применяемое fail-closed — break-glass и критические согласования отклоняются ниже аппаратно проверенной планки AAL3, а сессия без свежей церемонии отображается как AAL1 и никогда не завышается (NIST SP 800-63B — целевой стандарт; соответствие не заявляется). SSO с одним IdP (OIDC/SAML) с управляемой запечатанной конфигурацией и SCIM-провижининг пользователей и групп входят в открытую сборку; мульти-IdP федерация по тенантам и принудительное SSO — Enterprise.

Identity и NHI — вопросы

Выполняет ли Olivares сегодня живую федерацию с Entra Agent ID, AWS AgentCore или Google Agent Identity?

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

Два агента делят одну сервисную учётную запись. Какой из них, по версии Olivares, действовал?

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

Поддерживаете ли вы повышение до WebAuthn AAL3 или PIV-CAC для привилегированных входов?

Да. Привилегированная сессия повышает уровень через WebAuthn/FIDO2 или сертификат смарт-карты PIV/CAC до аппаратно проверенной планки AAL3 из NIST SP 800-63B — это целевой стандарт; соответствие NIST или FIPS не заявляется. Повышение работает fail-closed: оно истекает после короткого окна свежести, сессия без проверенной церемонии отображается как AAL1, а break-glass и критические согласования отказываются продолжать ниже AAL3.

Есть ли у вас SSO и SCIM-провижининг?

Да. Открытая сборка включает SSO с одним IdP (OIDC и SAML) с управляемой конфигурацией на основе хранилища — секреты запечатаны при хранении, запись конфигурации защищена повышением до AAL3 — плюс SCIM-провижининг пользователей и групп. Что даёт группа каталога, остаётся решением оператора: сопоставления ролей никогда не записываются со стороны IdP. Мульти-IdP федерация по тенантам и принудительная политика SSO — возможности Enterprise.

Дайте своим агентам идентичности, по которым можно атрибутировать действия

Разверните Olivares в собственной инфраструктуре, выпустите отдельную NHI для каждого агента и превратите «приблизительно» в «уверенно» на вашей карте доступа.