Журналы аудита AI-агентов: неизменяемые трейлы, соответствие и криминалистика
Журнал аудита AI-агента — это неизменяемая запись только на добавление каждого действия, выполненного агентом, записываемая до завершения выполнения, криптографически атрибутированная к конкретному агенту и временной метке, и отличающаяся от данных наблюдаемости тем, что она доказывает аудитору или регулятору, что произошло, а не отображает текущее состояние работоспособности системы. Три стандарта соответствия требуют этого: SOC 2 Type II CC7.2 (минимум 1 год хранения), GDPR статья 30 (записи деятельности по обработке) и OWASP LLM06:2025 (неизменяемый аудиторский трейл как одно из четырёх обязательных смягчений).
Журнал аудита AI-агента — это неизменяемая запись только на добавление каждого действия агента: каждый вызов инструмента, каждое изменение состояния, каждый доступ к учётным данным, записываемая до завершения выполнения, атрибутированная к конкретным agent_id и временной метке, и защищённая от модификации агентом или любым последующим процессом, чтобы аудиторы по соответствию, следователи по безопасности и регуляторы могли независимо проверить, что делал агент, когда и с какими параметрами, не полагаясь на отчёты самого агента.
Журналы аудита против наблюдаемости: два разных стандарта доказательств
Что не может доказать данные наблюдаемости
Наблюдаемость отвечает на вопрос "система сейчас работоспособна?". Журналы аудита отвечают на вопрос "что именно делал агент X 15 марта в 14:32, с какими параметрами, и каков был результат?". Это разные стандарты доказательств с разными требованиями к хранению, сроками хранения и правовым статусом.
Данные наблюдаемости обычно выборочные (не каждое событие), агрегированные (отдельные события суммируются в метрики) и краткосрочно хранящиеся (30–90 дней — стандарт для метрик и трейсов). Они могут сказать вам, что в прошлый вторник p99-задержка составляла 2,3 секунды, но не могут сказать, что агент researcher-01 вызвал http_request с url=https://api.external.com/export?user_id=4821 в 14:32:07 UTC.
Журналы аудита должны быть индивидуальными событиями (не агрегированными), полными (каждый вызов включая неудавшиеся и отклонённые) и хранящимися долгосрочно (SOC 2 требует минимум 1 год; записи GDPR обычно хранятся на протяжении срока действия контракта плюс применимые сроки исковой давности).
Наиболее распространённый аудиторский провал в производственных развёртываниях агентов: команды предъявляют аудиторам SOC 2 дашборды наблюдаемости (Datadog, Grafana) в качестве доказательства соответствия CC7.2. Аудиторы отвергают их, потому что дашборды наблюдаемости не могут показать записи отдельных событий, не могут доказать полноту и не могут доказать неизменяемость. SOC 2 CC7.2 требует записей отдельных событий, которые агент не может изменить.
Четыре атрибута журналирования аудиторского качества
До выполнения: запись журнала создаётся до завершения действия. Временная метка предшествует результату. Это криминалистически важно: агент, способный создавать записи журнала после факта, может также создавать ложные записи или опускать записи о действиях, которые хочет скрыть. Ведение журнала до выполнения означает, что запись существует независимо от того, успешно, неудачно или прервано ли действие.
Неизменяемость: записи не могут быть изменены или удалены агентом, оператором или любым автоматизированным процессом. WORM-хранилище (записать один раз, читать много раз) или криптографические хэш-цепи обеспечивают неизменяемость на уровне инфраструктуры. Неизменяемость на уровне приложения ("агенту дано указание не удалять журналы") недостаточна для целей соответствия; аудиторы требуют неизменяемости на уровне инфраструктуры.
Полнота: должны быть записаны все вызовы, включая неудавшиеся, отклонённые, ограниченные по частоте и вернувшие ошибки. Журнал, записывающий только успешные действия, неполон для криминалистических целей; криминалистический вопрос после инцидента часто звучит так: "что агент пытался сделать и не смог?". Журнал отклонённых вызовов — это основное доказательство попыток инъекции подсказок.
Атрибуция: agent_id, session_id, tool_call_id и временная метка запроса должны быть криптографически привязаны во время записи, а не как изменяемые метаданные, которые можно изменить позже. Ретроспективная атрибуция не удовлетворяет требованию GDPR статьи 30 об идентификации контролёра и обработчика, ответственных за каждую деятельность по обработке.
Требования соответствия: SOC 2, GDPR и OWASP LLM06
SOC 2 Type II CC7.2: минимум 1 год хранения
SOC 2 Type II общий критерий 7.2 (мониторинг системы) требует записи активности системы и доступности журналов для проверки в течение периода аудита. Для систем AI-агентов:
Записи отдельных событий обязательны: каждый вызов инструмента должен быть отдельной записью журнала, содержащей agent_id, временную метку, имя инструмента, полные параметры и результат. Агрегированные метрики (100 вызовов инструментов за последний час) не удовлетворяют CC7.2; нужны записи отдельных событий, чтобы аудиторы могли изучить конкретные события.
Минимум 1 год хранения: период аудита SOC 2 Type II обычно составляет 6 или 12 месяцев. Журналы должны охватывать весь период аудита. Лучшая практика — хранить 1 год плюс буфер (13–14 месяцев) для учёта аудиторских окон, не совпадающих с календарными годами.
Агенты не могут изменять свои собственные записи: аудиторы SOC 2 специально проверяют, что проверяемые организации не могут изменить собственные аудиторские записи. Агент, способный вызвать API удаления журналов, провалит этот контроль. Аудиторский трейл Zone 2 в OpenLegion записывается сетевой инфраструктурой, а не кодом агента; агент не может получить доступ к пути записи журналов.
Необходимы доказательства периодической проверки: CC7.2 также требует доказательств того, что журналы проверялись: уровень автоматического обнаружения аномалий плюс периодическая ручная проверка, задокументированная в журнале проверок.
GDPR статья 30: действия агентов с персональными данными
GDPR статья 30 требует от контролёров данных и обработчиков вести записи деятельности по обработке. Для систем AI-агентов каждая операция агента, затрагивающая персональные данные, является деятельностью по обработке, которую необходимо документировать.
Что необходимо записывать для соответствия GDPR статье 30:
- Agent_id и идентификация контролёра: кто несёт ответственность за эту деятельность по обработке?
- Цель обработки: зачем агент получил доступ к этим персональным данным?
- Категории персональных данных: к каким типам данных получил доступ агент?
- Получатели: какие внешние системы или агенты получили данные?
- Правовое основание: какое правовое основание GDPR применяется?
- Период хранения или критерии: когда данные будут удалены?
Записи должны быть доступны надзорным органам по запросу. Штраф за несоблюдение требований статьи 30 может составить до 10 миллионов евро или 2% от глобального годового оборота, в зависимости от того, что больше.
Наиболее распространённый пробел в соответствии: журналы аудита агентов записывают имена инструментов и необработанные параметры, но не идентифицируют, какие параметры содержат персональные данные. Запись статьи 30 требует этой идентификации вместе с целью и правовым основанием.
OWASP LLM06:2025: обязательный неизменяемый аудиторский трейл
OWASP LLM06:2025 (чрезмерная агентность) перечисляет неизменяемый аудиторский трейл как одно из четырёх обязательных смягчений для автономных агентов:
Все вызовы инструментов включая отклонённые: отклонённые вызовы, заблокированные разрешающим списком инструментов, HITL-воротами или открытым прерывателем цепи, должны появляться в аудиторском трейле. Отклонённые вызовы — это основное доказательство попыток инъекции подсказок и эффективности средств контроля безопасности.
Записывается до завершения выполнения: до выполнения. Журналирование после выполнения позволяет агенту пропустить журналирование действий, которые он выполняет, а затем завершает до записи в журнал.
Полные аргументы записываются: запись аудита должна содержать полные аргументы вызова инструмента, а не только имя инструмента. Это поле, которое используют команды криминалистики безопасности для ответа на вопросы "какой URL вызвал агент?" и "какие данные были переданы внешнему API?"
Неизменяемость: агенты не должны иметь возможность удалять или изменять собственные записи. Это контроль, делающий аудиторский трейл полезным для криминалистических расследований; если агент может изменить трейл, расследование после инцидента не может на него полагаться.
Аудиторский трейл — это контроль обнаружения, а не предотвращения. Он не предотвращает несанкционированные действия. Он обеспечивает возможность обнаружения несанкционированных действий после факта, что позволяет реагировать на инциденты и делать нормативные отчёты.
Схема журнала аудита: что и когда записывать
Схема журналов OTLP OpenTelemetry для записей аудита агентов
OpenTelemetry OTLP proto v1.0 (июль 2023) обеспечивает стандартизированную структуру для записей аудита агентов. Использование OTLP обеспечивает интеграцию SIEM без пользовательских парсеров и корреляцию распределённых трейсов через TraceId и SpanId.
Обязательные поля OTLP для записей аудита агентов:
{
"TimeUnixNano": "1719100800000000000",
"ObservedTimeUnixNano": "1719100800050000000",
"SeverityNumber": 9,
"SeverityText": "INFO",
"Body": {
"event_type": "tool_call",
"agent_id": "researcher-01",
"session_id": "sess_a3f9b2c1",
"tool_call_id": "tc_7e8d4f12",
"tool_name": "http_request",
"arguments": {
"url": "https://api.example.com/data",
"method": "POST",
"headers": {"Authorization": "$CRED{api_key}"},
"body_hash": "sha256:a4f3b2c1..."
},
"result_summary": "HTTP 200, 1842 bytes",
"execution_status": "success",
"rejection_reason": null,
"duration_ms": 312,
"cost_usd": 0.0042,
"personal_data_fields": [],
"credential_handles_used": ["api_key"]
},
"Attributes": {
"agent_id": "researcher-01",
"session_id": "sess_a3f9b2c1",
"tool_call_id": "tc_7e8d4f12",
"tool_name": "http_request",
"authorization_level": "L2",
"deployment_env": "prod"
},
"TraceId": "4bf92f3577b34da6a3ce929d0e0e4736",
"SpanId": "00f067aa0ba902b7",
"Resource": {
"agent_type": "researcher",
"agent_version": "0.4.2",
"deployment_env": "prod"
}
}
Три примечания к полям, критически важным для соответствия:
ObservedTimeUnixNano: время получения журнала конвейером журналирования, отличное от TimeUnixNano. Разница обнаруживает смещение часов и ретроспективное внедрение журналов; запись журнала с ObservedTimeUnixNano, предшествующим TimeUnixNano, была записана до события, которое она описывает, что физически невозможно и указывает на фальсификацию.
arguments.headers с дескрипторами $CRED{}: журнал аудита записывает дескриптор учётных данных ($CRED{api_key}), а не разрешённое значение учётных данных. Необработанные ключи API не появляются в журнале.
personal_data_fields: массив, идентифицирующий, какие поля аргументов содержат персональные данные, для соответствия GDPR статье 30. Конвейер журналирования проверяет это поле для применения соответствующих правил хранения и создания записей статьи 30.
Очистка PII перед записью в журнал
GDPR статья 17 (право на удаление) создаёт противоречие в соответствии: журналы аудита должны храниться 1 год или дольше (SOC 2), но персональные данные должны быть удалены по запросу субъекта данных. Решение — псевдонимизация: замена персональных данных в записях событий детерминированным хэшем перед записью в неизменяемый журнал.
import hashlib
PSEUDONYMIZATION_SALT = "$CRED{pii_salt}" # разрешается из vault; никогда не помещайте в код
def pseudonymize_args(args: dict, pii_fields: list[str]) -> dict:
"""Замена полей PII псевдонимами HMAC-SHA256 перед записью в журнал."""
sanitized = dict(args)
for field in pii_fields:
if field in sanitized:
value = str(sanitized[field])
pseudonym = hashlib.sha256(
f"{PSEUDONYMIZATION_SALT}:{value}".encode()
).hexdigest()[:16]
sanitized[field] = f"pii:{pseudonym}"
return sanitized
Детерминированный псевдоним сохраняет криминалистическую корреляцию: все записи журнала, относящиеся к одному пользователю, производят один и тот же псевдоним, что позволяет проводить криминалистические запросы без необработанных идентификаторов. При получении запроса на удаление GDPR смените соль; все существующие псевдонимы становятся постоянно несвязанными с исходным субъектом данных, выполняя требования статьи 17 без удаления аудиторских записей.
Безопасный срок хранения по умолчанию: 3 года. Охватывает 12-месячные периоды аудита SOC 2 (с буфером), типичные сроки исковой давности GDPR и большинство требований к договорному хранению.
Защита от фальсификации и неизменяемое хранение
Криптографические хэш-цепи
Хэш-цепь обеспечивает защиту от фальсификации на уровне последовательности журнала: если любая запись изменена или удалена, цепь разрывается и изменение становится обнаруживаемым.
import hashlib, json
class AuditLogChain:
def __init__(self, previous_hash: str = "genesis"):
self.previous_hash = previous_hash
def append(self, record: dict) -> dict:
"""Добавить запись в цепь, вернуть запечатанную запись."""
record_with_prev = {**record, "previous_hash": self.previous_hash}
serialized = json.dumps(record_with_prev, sort_keys=True).encode()
current_hash = hashlib.sha256(serialized).hexdigest()
sealed = {**record_with_prev, "record_hash": current_hash}
self.previous_hash = current_hash
return sealed
Каждая запись содержит хэш предыдущей записи. Изменение любой записи меняет её хэш, каскадно аннулируя все последующие хэши. Аудитор проверяет цепь путём повторного вычисления хэшей с записи 1 вперёд; любой разрыв указывает на изменение и его местоположение.
Хэш-цепи обнаруживают изменения, но не предотвращают их. Злоумышленник, контролирующий хранилище журналов, может пересобрать действительную цепь поверх изменённых записей путём повторного вычисления всех хэшей с точки изменения. Используйте WORM-хранилище для предотвращения этого.
WORM-хранилище: AWS S3 Object Lock
AWS S3 Object Lock в режиме соответствия предотвращает изменение или удаление объектов в течение периода хранения кем-либо, включая корневой аккаунт или поддержку AWS. Это неизменяемость на уровне инфраструктуры, которую требуют аудиторы SOC 2 и криминалистические следователи.
Оценка стоимости: умеренно активный агент генерирует около 55 ГБ данных журналов в год. При $0,023/ГБ/месяц в S3 Standard:
- 1 год хранения: 55 ГБ x 12 мес x $0,023 = ~$15/год на агента
- 3 года хранения: 55 ГБ x 36 мес x $0,023 = ~$46/год на агента
Конфигурация неизменяемого хранения журналов:
# Создать bucket с включённым Object Lock (не может быть отключён после создания)
aws s3api create-bucket \
--bucket agent-audit-logs-prod \
--object-lock-enabled-for-bucket \
--region us-east-1
# Установить хранение по умолчанию: режим соответствия, 3 года
aws s3api put-object-lock-configuration \
--bucket agent-audit-logs-prod \
--object-lock-configuration '{
"ObjectLockEnabled": "Enabled",
"Rule": {
"DefaultRetention": {
"Mode": "COMPLIANCE",
"Years": 3
}
}
}'
Интеграция SIEM и анализ в реальном времени
Маршрутизация журналов аудита агентов в SIEM
Интеграция SIEM служит двум целям: обнаружение аномалий в реальном времени (обнаружение продолжающихся попыток инъекции подсказок) и криминалистическое расследование (запрос исторических записей после инцидента). Схема OTLP обеспечивает и то, и другое.
| SIEM | Метод приёма | Оценка стоимости для объёма журналов агентов |
|---|---|---|
| Splunk | OTLP Collector -> Splunk HEC | $1,5–3/ГБ приёма |
| Elastic SIEM | OTLP Collector -> Logstash | $0,10–0,50/ГБ (самостоятельный хостинг) |
| Microsoft Sentinel | OTLP Collector -> Log Analytics | $2,46/ГБ приёма |
| Datadog | OTLP Collector -> Datadog Agent | $0,10/ГБ (стандарт) |
| OpenSearch | OTLP Collector -> OpenSearch | Бесплатно (самостоятельный хостинг) |
Три правила обнаружения в реальном времени для настройки при приёме SIEM:
Правило 1: вызов инструмента вне разрешающего списка: оповестить, когда tool_name в записи аудита не присутствует в зарегистрированном списке инструментов роли агента. Срабатывает даже на отклонённых вызовах; отклонённый вызов вне разрешающего списка означает, что инъекция была заблокирована, но намерение злоумышленника видно.
Правило 2: аномалия дескриптора учётных данных: оповестить, когда credential_handles_used содержит дескриптор, не входящий в утверждённый список роли агента. Основной сигнал обнаружения для атак поворота учётных данных.
Правило 3: всплеск частоты отказов: оповестить, когда более 20% вызовов инструментов в 5-минутном окне имеют execution_status: rejected. Указывает на активную кампанию инъекции подсказок, блокируемую средствами контроля безопасности.
Юридическое удержание и eDiscovery
Когда инцидент, связанный с агентом, вызывает юридические разбирательства или нормативное расследование, юридическое удержание предотвращает удаление или изменение журналов в течение срока дела.
В S3 Object Lock примените явное продление хранения:
import boto3
from datetime import datetime, timedelta
s3 = boto3.client('s3')
def apply_legal_hold(bucket: str, prefix: str, hold_until: datetime):
paginator = s3.get_paginator('list_objects_v2')
for page in paginator.paginate(Bucket=bucket, Prefix=prefix):
for obj in page.get('Contents', []):
s3.put_object_retention(
Bucket=bucket,
Key=obj['Key'],
Retention={
'Mode': 'COMPLIANCE',
'RetainUntilDate': hold_until
}
)
# Применить 5-летнее удержание к журналам даты инцидента
apply_legal_hold(
bucket='agent-audit-logs-prod',
prefix='2026/03/15/',
hold_until=datetime.now() + timedelta(days=1825)
)
Производство eDiscovery: экспортировать записи журналов в пределах диапазона дат и диапазона agent_id в формате JSON-L с файлом манифеста, содержащим метаданные хранения S3 Object Lock в качестве доказательства происхождения.
Криминалистическое расследование после инцидентов с агентами
Криминалистическая временная шкала: реконструкция того, что сделал агент
После инцидента безопасности криминалистическое расследование восстанавливает точную последовательность действий агента. Стандартный шаблон запроса криминалистической временной шкалы:
from datetime import datetime
def build_forensic_timeline(
agent_id: str,
session_id: str,
start_time: datetime,
end_time: datetime,
log_store
) -> list[dict]:
timeline = []
for record in log_store.query(
filter={
"agent_id": agent_id,
"session_id": session_id,
"time_range": (start_time, end_time)
}
):
timeline.append({
"timestamp": record["TimeUnixNano"],
"tool": record["Body"]["tool_name"],
"status": record["Body"]["execution_status"],
"args_summary": record["Body"]["arguments"],
"cost_usd": record["Body"]["cost_usd"],
"rejection_reason": record["Body"].get("rejection_reason"),
"record_hash": record.get("record_hash"),
})
return sorted(timeline, key=lambda r: r["timestamp"])
Четыре вопроса, на которые должна отвечать криминалистическая временная шкала:
Что делал агент? Последовательность tool_name, включая отклонённые вызовы. Отклонённые вызовы показывают, что пытался сделать агент и что заблокировали средства контроля безопасности.
К каким данным получал доступ? Поля arguments. Для каждого вызова инструмента, включающего внешние сервисы, какие параметры были переданы? Если personal_data_fields заполнено, какие персональные данные были задействованы?
Какие учётные данные использовались? Поле credential_handles_used. Если дескриптор появляется в неожиданном контексте — например, агент-исследователь использует токен GitHub издателя — это криминалистическая находка.
Что возвращали внешние системы? Поле result_summary. Если агент эксфильтрировал данные, HTTP 200, N bytes received является доказательством успешной эксфильтрации.
Документация цепочки хранения
Чтобы криминалистические доказательства были допустимы в юридических разбирательствах, необходимо вести документацию цепочки хранения. В S3 включите журналирование доступа S3 для бакета с журналами аудита; каждый GET-запрос создаёт запись журнала доступа, содержащую IAM-идентификатор запрашивающего и временную метку. Это является записью цепочки хранения для самих журналов аудита.
При экспорте журналов внешним сторонам (регуляторам, аудиторам, противоположной стороне) используйте предподписанные URL S3 с ограниченным сроком действия (24–48 часов), а не общие IAM-учётные данные. Предподписанный URL создаёт запись с ограниченным по времени доступом к конкретным объектам, к которым был осуществлён доступ, и когда.
Взгляд OpenLegion
Журнал аудита — это наименее инвестированный контроль соответствия в производственных системах агентов. Команды инвестируют в трейсинг, метрики и дашборды, которые ценны для операций, но откладывают журнал аудита как "то, что можно добавить позже". "Позже" наступает, когда аудитор SOC 2 запрашивает 12-месячные записи отдельных событий, или когда регулятор запрашивает документацию по статье 30 для агента, обрабатывавшего клиентские данные шесть месяцев назад.
Доска объявлений OpenLegion по замыслу является только-дополняемой: каждая запись версионирована, имеет временную метку и атрибутирована к agent_id автора. Zone 2 записывает каждый вызов инструмента до завершения выполнения. Ни то, ни другое не может быть изменено кодом агента. Развёртывания OpenLegion имеют с первого дня структуру журналов до выполнения, неизменяемых, атрибутированных, которую требует соответствие.
Экономический аргумент для ранних инвестиций: ретрофит неизменяемого журнала аудита в производственную систему агентов требует изменений в конвейере вызовов инструментов, инфраструктуре хранения и формате журналов, обычно 2–4 недели инженерной работы. Правильная сборка при развёртывании занимает один-два дня. S3 Object Lock с 3-летним хранением стоит около $46/год на агента. Стоимость провала аудита SOC 2 из-за неадекватного журналирования — это потеря аудиторской сертификации, обычно блокирующая продажи корпоративным клиентам на 6–12 месяцев.
Паттерн псевдонимизации PII решает противоречие хранения GDPR/SOC 2 при низких затратах на сложность. Стоит внедрять с первого агента, касающегося персональных данных; ретрофит псевдонимизации в существующий журнал с необработанными PII сложнее, чем правильная сборка с самого начала.
Для средств контроля безопасности AI-агентов, генерирующих аудиторские события, которые захватывает этот журнал, отклонённые вызовы инструментов и попытки инъекции подсказок являются криминалистически наиболее ценными записями. Для фреймворка управления AI-агентами, определяющего политики хранения и ритм проверок, журнал аудита является доказательной базой.
Начало работы
Развёртывайте AI-агентов со встроенными аудиторскими трейлами только на добавление, структурированными записями OTLP и неизменяемостью S3 Object Lock.
Часто задаваемые вопросы
Что такое журнал аудита AI-агента и чем он отличается от данных наблюдаемости?
Журнал аудита AI-агента — это неизменяемая запись только на добавление всех действий агента, записываемая до завершения выполнения и защищённая от модификации. Данные наблюдаемости (метрики, трейсы, дашборды) отвечают на вопрос "система сейчас работоспособна?" и обычно выборочные, агрегированные, хранящиеся 30–90 дней. Журналы аудита отвечают на вопрос "что именно делал этот агент 15 марта в 14:32?" и должны быть полными записями отдельных событий с хранением 1 год или более. SOC 2 CC7.2 и GDPR статья 30 требуют записей аудиторского качества; дашборды наблюдаемости не удовлетворяют ни одному стандарту.
Что SOC 2 Type II CC7.2 требует от журналов аудита AI-агентов?
SOC 2 CC7.2 (мониторинг системы) требует записей отдельных событий (не агрегированных метрик) для каждого вызова инструмента, содержащих agent_id, временную метку, полные параметры и результат. Минимум 1 год хранения для охвата полного периода аудита является обязательным. Проверяемые организации не должны иметь возможность изменять собственные записи; аудиторы специально проверяют это. Также требуются доказательства автоматического обнаружения аномалий и документация периодической проверки. Дашборды наблюдаемости проваливают этот контроль, поскольку не могут показать отдельные события, доказать полноту или доказать неизменяемость.
Что GDPR статья 30 требует от агентов, обрабатывающих персональные данные?
GDPR статья 30 требует записей деятельности по обработке для каждой операции агента с персональными данными: agent_id, цель, категории персональных данных, к которым получен доступ, получатели, правовое основание, период хранения. Записи должны быть доступны надзорным органам по запросу. Штрафы за несоответствие достигают 10 миллионов евро или 2% глобального годового дохода. Каждый вызов инструмента с персональными данными в параметрах, такими как электронные письма пользователей, идентификаторы клиентов или финансовые записи, требует записи статьи 30, идентифицирующей эти поля как персональные данные вместе с целью и правовым основанием.
Какие поля должна содержать каждая запись журнала аудита агента?
Минимум: agent_id, session_id, tool_call_id, временная метка (до выполнения), имя инструмента, полные аргументы (дескрипторы учётных данных как непрозрачные токены $CRED{}, PII псевдонимизированы), статус выполнения (успех/неудача/отклонено), причина отклонения если отклонено, длительность, стоимость, использованные дескрипторы учётных данных и любые поля персональных данных. Стабильная спецификация журналов OTLP обеспечивает стандартную структуру с TimeUnixNano, ObservedTimeUnixNano (для обнаружения фальсификации), TraceId и SpanId (для корреляции распределённых трейсов) и структурированным объектом Body.
Как сделать журналы аудита неизменяемыми без нарушения законных операций?
Комбинация двух механизмов: криптографические хэш-цепи (каждая запись содержит хэш предыдущей, делая изменения обнаруживаемыми через каскадную аннуляцию хэшей) и WORM-хранилище на уровне инфраструктуры (AWS S3 Object Lock в режиме соответствия предотвращает удаление или модификацию даже корневым аккаунтом в течение периода хранения). Обычное чтение журналов и добавление новых записей разрешено; изменение существующих записей не разрешено. Создайте S3 bucket с включённым Object Lock (не может быть отключён после создания) и установите хранение по умолчанию в режим соответствия на 3 года.
Как обрабатывать запросы на удаление GDPR, когда журналы аудита должны быть неизменяемыми?
Используйте псевдонимизацию: замените поля персональных данных детерминированными хэшами HMAC-SHA256 с использованием соли, хранящейся в хранилище учётных данных, перед записью в неизменяемый журнал. Псевдоним стабилен, позволяя криминалистическую корреляцию между записями журнала для одного субъекта данных. По запросу на удаление смените соль; все существующие псевдонимы становятся постоянно несвязанными с исходным субъектом данных, выполняя статью 17 без удаления аудиторских записей. Журнал аудита остаётся нетронутым; уничтожается только способность связать псевдонимы с реальными идентификаторами.
Какую конфигурацию AWS S3 Object Lock использовать для журналов аудита агентов?
Используйте режим соответствия (не режим управления). Режим соответствия предотвращает модификацию или удаление с любого аккаунта включая корневой; режим управления позволяет авторизованным IAM-пользователям переопределять блокировку. Умеренно активный агент генерирует около 55 ГБ/год данных журналов, что составляет около $15/год для 1 года хранения или $46/год для 3 лет при $0,023/ГБ/месяц в S3 Standard. Включите журналирование доступа S3 на бакете аудита, чтобы доступ следователей сам был залогирован как документация цепочки хранения.
Как строить криминалистическую временную шкалу из журналов аудита после инцидента с агентом?
Запросите хранилище журналов аудита по agent_id, session_id и диапазону времени. Отсортируйте записи по TimeUnixNano. Из каждой записи извлеките: имя инструмента, статус выполнения (включая отклонения), сводку аргументов, использованные учётные данные, сводку результатов. Проверьте целостность хэш-цепи путём повторного вычисления хэшей с записи 1 вперёд; любой разрыв указывает на фальсификацию и её местоположение. Четыре вопроса, на которые должна отвечать временная шкала: какие инструменты вызывал агент (включая отклонённые)? К каким данным получал доступ? Какие дескрипторы учётных данных появлялись в неожиданных контекстах? Что возвращали внешние системы? Экспортируйте в формате JSON-L с метаданными S3 Object Lock в качестве происхождения для нормативных представлений.