"Мы привыкли, что идентификация, это про человека. Но что, если субъектом станет ИИ-агент, цифровой двойник или кибернетический организм? Регуляторная рамка 152-ФЗ и ФСТЭК не готова к этому, и это создаёт слепые зоны, где безопасность превращается в фикцию."
От пользователя к сущности: почему старые модели идентификации не работают
Традиционные системы аутентификации построены вокруг человека. Логин и пароль, токены, биометрия — всё это привязано к физическому лицу, его уникальным биологическим или поведенческим признакам. Даже квалифицированная электронная подпись (КЭП) юридически удостоверяет волю конкретного человека.
Однако цифровая среда эволюционирует. Появляются автономные программные агенты, выполняющие задачи без прямого вмешательства человека: торговые боты, системы мониторинга, ИИ-ассистенты, управляющие инфраструктурой. Цифровые двойники — виртуальные копии физических объектов или процессов — начинают самостоятельно взаимодействовать с другими системами, обмениваясь данными и принимая решения. В перспективе — гибридные формы: нейроинтерфейсы, стирающие границу между мозгом и компьютером, или кибернетические организмы.
Эти сущности не являются «пользователями» в классическом понимании. У них нет паспорта, отпечатков пальцев или голоса для биометрии. Их «идентичность», это совокупность кода, конфигурации, истории действий и, возможно, обучаемой модели. Аутентифицировать такого субъекта по схеме «что-то, что ты знаешь/имеешь/есть» становится невозможно. Это фундаментальный разрыв между технологической реальностью и регуляторными ожиданиями.
Слепые зоны 152-ФЗ: где регуляторика молчит
152-ФЗ «О персональных данных» и сопутствующие акты ФСТЭК заточены под защиту информации о физических лицах. Ключевые понятия — «персональные данные», «субъект ПДн», «оператор». В этой парадигме нечеловеческая сущность либо игнорируется, либо рассматривается как инструмент в руках оператора.
Это создаёт несколько критичных слепых зон:
- Ответственность за действия агента. Если автономный ИИ-агент, имеющий доступ к государственной информационной системе (ГИС), совершит действие, приводящее к утечке или искажению данных, кто будет нести ответственность? Разработчик, владелец, оператор системы? В текущей правовой рамке нет чёткого ответа.
- Учёт и аудит. Требования ФСТЭК предписывают учёт действий пользователей. Но как логировать действия агента, который генерирует тысячи событий в секунду? Записывать каждый вызов API? Или только итоговое решение? Как отличить сбой агента от целенаправленной вредоносной активности?
- Контур защиты. Средства защиты информации (СЗИ) настраиваются на контроль доступа пользователей. Если доступ получает не пользователь, а доверенный агент, контур защиты де-факто переносится на механизмы аутентификации самого агента, которые часто остаются вне поля зрения регулятора.
Фактически, организация может формально соблюдать все требования ФСТЭК, но при этом иметь уязвимый канал в виде неконтролируемых нечеловеческих субъектов.
Новая парадигма аутентификации: не «кто», а «что и на каком основании»
Для posthuman-сущностей нужен сдвиг в логике. Вместо идентификации личности требуется верификация легитимности сущности и её мандата на действие.
Это можно представить как многоуровневую модель:
- Аутентификация сущности. Подтверждение, что это именно тот заявленный агент, а не его копия или злоумышленник. Здесь могут применяться криптографические методы: сертификаты, вшитые в код или аппаратное обеспечение, или механизмы атрибутного доступа на основе хеша и метаданных программы.
- Верификация мандата (полномочий). Что этой сущности разрешено делать? Мандат, это динамический набор правил: «агент X имеет право читать данные из базы Y в период с 10:00 до 18:00 и записывать результаты в лог Z». Мандат должен быть подписан владельцем (человеком или другой доверенной системой) и иметь ограниченный срок жизни.
- Контекстуальная оценка. Даже аутентифицированной сущности с валидным мандатом может быть отказано в доступе, если её поведение отклоняется от ожидаемого паттерна (аномалии в запросах, подозрительная частота действий).
Технические прототипы и российский контекст
Хотя единого стандарта нет, некоторые подходы уже прорабатываются в мире и могут быть адаптированы. Ключевое — использование инфраструктуры открытых ключей (PKI) и технологий распределённого реестра.
Например, концепция «идентификаторов децентрализованных идентификаторов» (DIDs) позволяет сущности иметь самодостаточный идентификатор, не зависящий от центрального реестра. Верифицируемые учётные данные (Verifiable Credentials) могут выступать в роли цифрового мандата. В российском сегменте логично рассматривать адаптацию этих идей на базе отечественной криптографии (ГОСТ) и, возможно, с привязкой к инфраструктуре КЭП, расширив её действие на нечеловеческие субъекты.
Практическая реализация может выглядеть так:
# Пример запроса агента к API с токеном, содержащим мандат
POST /api/v1/data
Authorization: Bearer eyJhbGciOi... # JWT, содержащий DID агента и подписанный мандат
Body: {"action": "read", "resource": "db://sensitive_table"}
# Сервис безопасности проверяет:
# 1. Подпись JWT (криптография ГОСТ).
# 2. Валидность и неистёкший срок мандата в payload токена.
# 3. Соответствие запрашиваемого действия ('read') разрешениям в мандате.
Главная сложность — интеграция таких механизмов с существующими СЗИ, сертифицированными ФСТЭК. Потребуется либо модификация этих средств, либо создание шлюзов-посредников, которые будут транслировать «права агента» в понятные для СЗИ «права пользователя».
Что делать сейчас: практические шаги для специалистов по безопасности
Ожидать быстрых изменений в законодательстве не стоит. Поэтому имеет смысл действовать на опережение внутри своих проектов.
- Инвентаризация нечеловеческих субъектов. Составьте реестр всех автономных агентов, микросервисов, скриптов и цифровых двойников, имеющих доступ к информационным ресурсам. Для каждого определите владельца и цель существования.
- Внедрение принципа наименьших привилегий. Назначьте каждому такому субъекту отдельную учётную запись (технического пользователя) с жёстко ограниченными правами. Это временное, но важное решение.
- Детальный аудит их действий. Настройте централизованное логирование не по учётной записи, а по идентификатору сущности. Анализируйте паттерны поведения для выявления аномалий.
- Эксперименты с криптографической аутентификацией. Протестируйте для внутренних сервисов аутентификацию на основе сертификатов или JWT, подписанных доверенным УЦ. Это станет основой для будущих решений.
- Диалог с регулятором. Поднимайте эту тему в рамках отраслевых рабочих групп. Отсутствие практики — не причина игнорировать проблему. Чем раньше она попадёт в поле зрения ФСТЭК, тем адекватнее будут будущие требования.
Итог: безопасность после человека
Постчеловеческая идентификация — не футуристическая абстракция, а насущная проблема безопасности. Автоматизированные системы уже сегодня создают тени в нормативном поле. Игнорируя их, мы строим защиту, которая смотрит в прошлое, пока угоры движутся вперёд.
Задача специалиста — увидеть этот разрыв. Не пытаться вписать агента в графу «ФИО», а проектировать системы безопасности, где легитимность действия доказывается криптографически, а не биографически. Это сложный переход, но он неизбежен. Те, кто начнёт прорабатывать эти вопросы сейчас, окажутся не только в правовом поле завтрашнего дня, но и создадут более устойчивую и целостную архитектуру безопасности уже сегодня.