Журнал аудита

Журнал аудита i1n записывает каждое изменение в организации — не как грубую строку «файл перевода обновлен», а как структурированное событие для каждого ключа и каждого языка. Когда пользователь панели управления изменяет испанский (es_mx) перевод errors.insufficient_funds в 14:32 UTC, журнал фиксирует точное значение до изменения, точное значение после изменения, идентификатор исполнителя, временную метку, IP-адрес и пользовательский агент запроса, который произвел изменение.

Покрытие охватывает всю поверхность платформы: создание, редактирование и удаление переводов; создание, переименование и удаление пространств имен; настройки проекта и изменения голоса бренда; приглашения в команду, изменения ролей и удаления; создание, ротацию, изменение области действия и удаление ключей API; изменения тарифного плана, события подписки и активация BYOK.

Массовые операции, такие как i1n push, создают одно событие для каждой измененной пары ключ-язык вместо единой общей сводки, с общим идентификатором пакета в метаданных. Push, обновляющий 200 ключей на четырех языках, создает 800 индивидуально адресуемых записей аудита, каждая со своим diff. Аудиторы, таким образом, могут ответить на вопрос «что изменилось 17 апреля в 14:32» вплоть до точной строки.

События генерируются триггерами PostgreSQL, прикрепленными к каждой аудируемой таблице. Нет пути записи на уровне приложения, который обходит журнал — каждая успешная мутация создает свою строку аудита в рамках той же транзакции базы данных. Изменение, которое зафиксировано без соответствующей строки аудита, по своей сути невозможно.

Каждая запись аудита помечается одним из пяти типов исполнителей: user для мутаций панели управления, cli для прямых операций командной строки, mcp для изменений, внесенных ИИ-агентом через сервер i1n MCP, webhook для событий, исходящих от внешних систем, таких как поставщик биллинга, и system для внутренних задач платформы, таких как очистка данных хранения.

Атрибуция пользователей на панели управления является криптографической. Идентификатором субъекта является идентификатор учетной записи аутентифицированного пользователя, отображаемый вместе с его подтвержденным адресом электронной почты и именем из списка членов организации. Администраторы, просматривающие журнал, видят реальные личности людей, а не непрозрачные UUID.

Атрибуция CLI и MCP криптографически связана с используемым ключом API, при этом префикс ключа записывается для криминалистической корреляции. Подсказки, полученные из конфигурации git разработчика — адрес электронной почты и полное имя — также фиксируются, но явно помечаются как непроверенные на панели управления. Это честное разделение между криптографической идентичностью и самостоятельно сообщаемыми метаданными — то, что аудиторы соответствия ожидают от зрелой системы аудита.

Наблюдаемость ИИ-агентов, насколько нам известно, уникальна для i1n. Каждое изменение перевода, сделанное Claude Code, Cursor или любым другим клиентом, подключенным к серверу i1n MCP, помечается как actor_type = 'mcp'. Организации могут фильтровать журнал аудита, чтобы ответить на вопрос «какие переводы были в последний раз изменены ИИ-агентом по сравнению с человеком-рецензентом» — вопрос, на который нет четкого ответа ни на одной другой платформе локализации.

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

Журнал аудита является только добавляемым на уровне базы данных. Триггеры выдают строки; путь INSERT не предоставляется клиентам, и в таблице нет политик UPDATE или DELETE. Члены организации не могут редактировать свою собственную историю. Сотрудники i1n operations также не могут редактировать или удалять записи — таблица защищена на уровне схемы, а не на уровне приложения.

Срок хранения составляет 365 дней, что соответствует базовому уровню контроля SOC 2 для журналов действий. Записи старше 365 дней удаляются запланированным заданием, которое само генерирует запись в журнале аудита — каждое удаление отслеживается. Организации, которым требуются более длительные периоды для конкретного нормативного обзора, могут запросить продление на уровне контракта.

Журнал отображает точки данных, которые обычно запрашивают специалисты по комплаенсу: кто, что, когда, где (IP-адрес), как (агент пользователя) и что изменилось (предыдущие и последующие значения, полностью). Для организаций, подпадающих под действие статьи 30 GDPR о ведении записей, или для финансовых регуляторов, требующих отслеживаемости пользовательского контента, экспорт является достаточным в качестве основного доказательства.

i1n в настоящее время не публикует отчет SOC 2 Type II на уровне платформы. Журнал аудита является основополагающим контролем, который поддерживает собственную программу соответствия клиента требованиям SOC 2, GDPR или финтех — он не заменяет организационные средства контроля, но устраняет наиболее распространенное препятствие при проверках соответствия, которым является отсутствие проверяемого следа изменений контента.

Доступ на чтение к журналу аудита ограничен владельцами организации и администраторами. Редакторы и просмотрщики не видят вкладку журнала аудита на панели управления и не могут запрашивать его через API. Это разделение обеспечивается безопасностью на уровне строк PostgreSQL, а не скрытием на стороне клиента — нет никакого способа прочитать журнал из непривилегированной роли.

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

Владельцы и администраторы не могут редактировать исторические записи. На вопросы «кто может читать» и «кто может изменять» намеренно даны разные ответы — чтение доступно на уровне администратора, изменение — никому. Это удовлетворяет ожиданиям по разделению обязанностей, которые аудиторы применяют при проверке внутренних средств контроля доступа.

Доступ к API отражает модель панели мониторинга. Журнал аудита предоставляется через те же политики безопасности на уровне строк, которые ограничивают доступ к панели мониторинга, поэтому любая учетная запись службы или токен интеграции, используемые для запроса журнала, автоматически наследуют те же ограничения.

Данные журнала аудита можно экспортировать в формате CSV с панели управления одним щелчком мыши. Экспорт охватывает любой выбранный временной диапазон и учитывает активные фильтры — тип исполнителя, тип события, проект и поисковый запрос — чтобы рецензентам можно было предоставить узкий срез, а не всю историю. CSV сохраняет полную детализацию: временную метку, организацию, проект, идентификатор исполнителя, тип исполнителя, префикс ключа API, тип события, сущность, предыдущее значение, следующее значение, IP-адрес, пользовательский агент и метаданные.

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

Журнал аудита автоматически активен во всех организациях Enterprise. Нет шагов по настройке, переключателя для включения или требуемой установки. Существующие клиенты Enterprise, включая belo, партнера по запуску, имеют заполненный журнал с момента выпуска функции, фиксирующий активность каждого дашборда, CLI и клиента MCP, подключенного к организации.

Организации на тарифах Pro или Business не имеют доступа к журналу аудита. Обновление до Enterprise немедленно активирует журнал и начнет запись событий с момента обновления; историческое сохранение данных до обновления не предоставляется. Свяжитесь с командой i1n, чтобы обсудить цены Enterprise для вашей организации.