Audit & lifecycle: audit logs, data retention, удаление по запросу, continuity/backups

1. Зачем вам вообще audit & lifecycle в ChatGPT App

Пока вы пишете прототип, пользователь — вы сами, БД — локальный SQLite, а «инциденты» лечатся git reset --hard, всё кажется милым и домашним.

Но как только ваш GiftGenius (или другое ChatGPT‑приложение (App)) получает настоящих пользователей, особенно с платежами и PII, внезапно появляются:

• безопасники клиента с вопросом «кто может увидеть наши заказы и кто их менял?»;
• юристы с вопросом «как долго вы храните данные и как выполняете запрос „удалить меня“?»;
• продакшн‑реальность с вопросом «что будет, если разработчик дропнет таблицу в проде?».

В этой лекции мы разберём четыре опорных блока:

1. Audit‑логи — отдельный слой логирования для безопасности и аудита.
2. Data retention — сроки жизни разных типов данных и как их реализовать.
3. Удаление по запросу пользователя — «право на забвение» в технике.
4. Business continuity & backups — как пережить сбои, не потеряв лицо и данные.

Все примеры будем по возможности привязывать к нашему учебному App (условный GiftGenius на Next.js + Apps SDK + MCP).

2. Audit‑логи: кто, что, когда и с чем это закончилось

Чем audit‑логи отличаются от обычных логов

Обычные application‑логи — это дружелюбные сообщения для разработчика. В них живут stack trace’ы, debug‑информация, странные значения переменных, отладочные console.log("вот тут точно не должно быть null"). Они живут недолго и читаются инженерами.

Audit‑логи — другая вселенная. Их основная аудитория — безопасники, аудиторы, иногда юристы. Им не нужна строка «NullPointer на 55‑й строке», им нужна запись вида «пользователь X изменил платёжные настройки организации Y в такое‑то время, результат — успешен». Audit‑записи обычно живут значительно дольше (годы) и считаются доказательством в случае расследований.

Ключевые отличия:

OWASP и подобные гайдлайны отдельно подчёркивают: audit‑логи лучше держать в отдельном хранилище или таблице, а не смешивать с обычными логами приложения.

Что логировать в контексте ChatGPT‑приложения

Для ChatGPT‑приложения, особенно с коммерцией, разумный минимум аудита такой:

• события аутентификации: логин, логаут, попытки входа;
• операции с критичными данными: создание/обновление/удаление профилей, заказов, платёжных настроек;
• административные действия: смена ролей, изменение настроек тенанта;
• вызовы чувствительных инструментов MCP/Agents: create_order, charge_customer, cancel_subscription и т.п.

Хорошая интуиция: всё, что при инциденте вы захотите спросить в стиле «кто это сделал и через что?», должно идти в аудит.

Структура события аудита

Удобная ментальная модель: каждая запись — это «кто / какое действие / над чем / в каком контексте / с каким исходом». Часто это формулируют как структуру who, action, resource, context, outcome.

Для нашего GiftGenius опишем интерфейс в TypeScript:

// lib/audit.ts
export type AuditAction =
  | "auth.login"
  | "auth.logout"
  | "order.create"
  | "order.cancel"
  | "account.delete"
  | "giftidea.generate";

export interface AuditEvent {
  eventId: string;          // uuid
  timestamp: string;        // ISO
  actor: {
    userId: string | null;  // может быть null до логина
    tenantId?: string | null;
    ip?: string | null;
    client: "chatgpt-app" | "admin-panel" | string;
  };
  action: AuditAction;
  resource?: {
    type: string;           // "order", "user", ...
    id?: string;
  };
  context?: {
    mcpTool?: string;
    requestId?: string;
  };
  outcome: {
    status: "success" | "failure";
    reason?: string | null;
  };
}

Заметьте, что в событие не попадают полные e‑mail, номера карт и прочая PII, которую мы по предыдущим лекциям учились маскировать и не логировать без нужды.

Где и как хранить audit‑логи

Минимальные требования к хранилищу:

• отдельная таблица или даже отдельная БД от обычных логов, чтобы сложнее было случайно что‑то затереть;
• по возможности режим append‑only: технически это может быть просто политика «мы никогда не делаем UPDATE/DELETE по этой таблице», плюс роль БД, у которой есть только права на INSERT и SELECT;
• ограниченный доступ: не весь инженерный штат должен иметь права читать полный audit.

Если вы используете PostgreSQL через Prisma/Drizzle, модель может выглядеть так (упрощённый пример):

CREATE TABLE audit_events (
  event_id   uuid PRIMARY KEY,
  created_at timestamptz NOT NULL DEFAULT now(),
  actor_user_id text,
  actor_tenant_id text,
  actor_ip      inet,
  action        text NOT NULL,
  resource_type text,
  resource_id   text,
  context_mcp_tool text,
  context_request_id text,
  outcome_status text NOT NULL,
  outcome_reason text
);

Схема адаптируется под ваши нужды, но главное — структурированность. JSON‑мусор одной строкой вы потом сами проклянете.

Реализация аудита в нашем App

Сделаем небольшой helper в Next.js‑приложении (Node‑окружение, например в MCP‑сервере или API‑роуте):

// lib/audit.ts
import { randomUUID } from "crypto";
import { db } from "./db"; // ваш клиент к БД

export async function logAudit(event: Omit<AuditEvent, "eventId" | "timestamp">) {
  const full: AuditEvent = {
    ...event,
    eventId: randomUUID(),
    timestamp: new Date().toISOString(),
  };

  // В реальной жизни — через очередь/фон, здесь просто вставка
  await db.insertInto("audit_events").values({
    event_id: full.eventId,
    created_at: full.timestamp,
    actor_user_id: full.actor.userId,
    action: full.action,
    outcome_status: full.outcome.status,
    outcome_reason: full.outcome.reason ?? null,
    // ...остальные поля
  });
}

Теперь добавим вызов в обработчик, который создаёт заказ (представим, что это MCP‑tool или серверный endpoint):

// app/api/orders/route.ts
export async function POST(req: Request) {
  const user = await requireUser(req); // из модуля аутентификации
  const body = await req.json();
  const order = await createOrderInDb(user, body);

  await logAudit({
    actor: { userId: user.id, client: "chatgpt-app" },
    action: "order.create",
    resource: { type: "order", id: order.id },
    context: { mcpTool: "create_order_tool" },
    outcome: { status: "success" },
  });

  return Response.json(order);
}

То же самое можно сделать вокруг опасных операций — отмена заказа, изменение платёжных реквизитов, удаление аккаунта.

У нас появился отдельный структурированный слой аудита — отлично. Следующий естественный вопрос: как долго все эти события (и остальные пользовательские данные) должны жить и что с ними делать по истечении срока?

3. Data retention: сколько живут ваши данные

Почему нельзя хранить всё вечно

Инженерный инстинкт «а вдруг пригодится» в контексте пользовательских данных — очень опасен.

Во‑первых, чем дольше и больше данных вы копите, тем тяжелее последствия в случае утечки: чем толстее бочка с бензином, тем страшнее пожар. Многие руководства по защите данных прямо называют данные «токсичным активом»: их надо хранить с пользой, но минимизировать объём и срок.

Во‑вторых, законодательство уровня GDPR/CCPA вводит принцип «не дольше, чем нужно для цели обработки». То есть персональные данные нельзя держать бесконечно «на всякий случай». Для каждого типа данных должны быть ясные сроки хранения и процедуры удаления или анонимизации.

В‑третьих, облачное хранилище стоит денег. Большие таблицы логов и истории чатов растут быстро, и через год внезапно оказывается, что половина счёта от провайдера — это «вчерашний мусор».

Разные данные — разные сроки

Опыт компаний и публичные гайдлайны дают примерно такую картинку:

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

Как реализовать retention в коде

Самый частый паттерн: у таблицы есть created_at или expires_at, и у вас есть периодический процесс, который удаляет или анонимизирует старые записи.

Пример: чистка обычных логов, старше 90 дней.

// scripts/cleanup-logs.ts
import { db } from "../lib/db";

async function cleanup() {
  await db
    .deleteFrom("app_logs")
    .where("created_at", "<", new Date(Date.now() - 90 * 24 * 60 * 60 * 1000));
  console.log("Old logs removed");
}

cleanup().catch(console.error);

Такой скрипт можно запускать по cron’у, через GitHub Actions по расписанию, либо с помощью планировщика облака.

Для PII вместо удаления часто делают анонимизацию. Например, заказы старше N лет лишаются связки с конкретным пользователем:

UPDATE orders
SET user_id = NULL
WHERE created_at < now() - interval '3 years';

При этом сохраняются суммы, товары и прочая «бухгалтерия», но пропадает связь с конкретной персоной.

Не забывайте, что у резервных копий тоже должны быть свои сроки жизни. Периодичность и длительность хранения бэкапов мы обсудим отдельно в блоке про бэкапы, но сама идея та же: даже архивы нельзя держать бесконечно, иначе «право на забвение» превращается в фикцию.

4. Удаление по запросу пользователя: «право на забвение» в коде

Откуда требование

Европейский GDPR (и похожие законы) вводит так называемое «право на забвение»: пользователь может потребовать удаления своих персональных данных, и компания должна сделать это без необоснованной задержки.

С точки зрения разработчика такого приложения это означает: рано или поздно вам прилетит запрос «удалите все данные обо мне» (или вы сами сделаете кнопку «Delete my data»), и нужно будет не только удалить запись в таблице users, но и пройтись по всему следу: заказы, сессии, токены, журналы действий, CRM, платёжки и т.п.

Но, есть и законы, которые требуют от вас хранить определенные данные: финансовые транзакции, например. Так что тут больше юридических сложностей, чем технических.

Что именно надо чистить

Минимальный набор для нашего GiftGenius:

• профиль пользователя (имя, e‑mail, настройки);
• сессии, refresh‑токены, связки с OAuth‑провайдерами;
• заказы, если они не нужны в «персонифицированном виде» (или их можно анонимизировать);
• логи и audit‑записи, где внутри лежит PII (например, e‑mail в сыром виде).

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

Пример алгоритма удаления

Схема сценария:

1. Пользователь (авторизованный) жмёт «Удалить мой аккаунт».
2. На сервер уходит запрос с его userId.
3. Сервер:
   • удаляет/анонимизирует зависимые записи (заказы, сессии, интеграции);
   • чистит PII в профиле;
   • пишет запись в audit‑лог «обработан запрос на удаление данных».

Для простоты покажем минимальный вариант на паре таблиц. В реальном продукте вокруг этого же ядра вы добавите дополнительные сущности (интеграции, сторонние сервисы и т.п.).

Сервисный код в Next.js (упрощённый пример):

// app/api/delete-me/route.ts
import { db } from "@/lib/db";
import { logAudit } from "@/lib/audit";

export async function POST(req: Request) {
  const user = await requireUser(req);

  await db.transaction(async (tx) => {
    await tx.deleteFrom("sessions").where("user_id", "=", user.id);
    await tx.deleteFrom("orders").where("user_id", "=", user.id);

    await tx.updateTable("users")
      .set({
        is_deleted: true,
        name: null,
        email: null,
      })
      .where("id", "=", user.id);

    await logAudit({
      actor: { userId: user.id, client: "chatgpt-app" },
      action: "account.delete",
      outcome: { status: "success" },
    });
  });

  return new Response(null, { status: 204 });
}

В реальном мире вы добавите сюда вызовы внешних API (например, Stripe — чтобы отвязать customer), да и транзакцию сделаете по‑серьёзнее. Но сам принцип уже есть: всё в одном месте, с audit‑записью.

Взаимосвязь с backup’ами

С хитрой частью «а как же бэкапы» связано множество интересных вопросов. Даже если вы удалили пользователя из боевой БД, его данные могут остаться в ночных snapshot’ах. Чтобы это не превращалось в «мы никогда никого не удаляем по факту», есть два подхода:

1. Бэкапы сами живут ограниченное время (например, 30–90 дней), и через это время исчезают вместе с данными. После истечения retention ни основная БД, ни архивы не содержат пользователя.
2. Если вы всё‑таки поднимаете систему из бэкапа, у вас есть реестр «удалённых» ID, и после восстановления вы повторно прогоняете скрипты удаления/анонимизации.

В больших компаниях иногда практикуют crypto‑shredding: PII пользователя шифруется отдельным ключом, и при запросе на удаление уничтожается именно ключ. Даже если где‑то остались копии зашифрованных данных (в логах, бэкапах), без ключа это бесполезный мусор. Это круто, но для стартапа немного «ракетная наука».

Важный UX‑момент

Помните, что удаление — это не только SQL. Пользователь ожидает:

• понятный способ отправить запрос (кнопка, форма, e‑mail);
• разумные сроки выполнения (на практике это до 30 дней);
• уведомление об успехе или мотивированный отказ (например, когда часть данных должны храниться по закону).

С технической стороны у вас уже всё готово: вы умеете провести чистку, залогировать действие и не хранить лишнего в бэкапах.

5. Business continuity & резервное копирование

Теперь представьте, что всё вышеперечисленное работает идеально… пока не происходит фатальный DROP TABLE orders, сбой в облаке или падение региона. Нам нужны механизмы, чтобы вернуть сервис к жизни в разумные сроки и не потерять критичные данные.

RTO и RPO — две буквы, определяющие вашу боль

Два базовых параметра Disaster Recovery:

• RTO (Recovery Time Objective) — сколько времени вы можете себе позволить быть недоступными. Например, если RTO = 1 час, значит после серьёзного сбоя вы обязаны поднять систему максимум за час.
• RPO (Recovery Point Objective) — сколько данных по времени вы готовы потерять. Если RPO = 10 минут, значит при восстановлении можно потерять последние 10 минут истории, но не больше.

Чем критичнее продукт (банкинг, торговые системы), тем ближе оба параметра к нулю. Для учебного GiftGenius можно жить с RTO ~ несколько часов и RPO ~ 15–60 минут, но даже это нужно как‑то реализовать.

Что может пойти не так в вашем стеке

В контексте ChatGPT‑приложения на Vercel + облачная БД + внешние API список типичных бед такой:

• OpenAI API недоступно: ваш App отвечает ошибками на tool‑calls.
• Vercel (или кто‑то ещё) даёт сбой: виджет не может достучаться до вашего backend’а.
• База данных повреждена или что‑то случайно удалено (например, DROP TABLE).
• Сломан или скомпрометирован аккаунт, управляющий инфраструктурой.

На всё это вы отвечаете комбинацией бэкапов, репликаций и разумного поведения приложения при сбое.

Стратегии резервного копирования

Современные облачные Postgres/другие БД обычно дают минимум три опции:

1. Полные бэкапы + инкрементальные.
   Делать полный snapshot БД раз в сутки и между ними хранить инкрементальные изменения. Восстановление — откат к конкретному snapshot’у плюс прокрутка журнала изменений.
2. Point‑in‑Time Recovery (PITR).
   База пишет журнал транзакций (WAL) и позволяет восстановиться на произвольный момент времени (например, «состояние на 14:03:00, до того как мы дропнули таблицу»).
3. Репликация в другой регион.
   Держать пассивную или активную реплику БД в другом регионе/облаке. При потере основного региона можно переключить приложение на реплику, потеряв только те данные, которые ещё не успели доехать.

Для нашего масштаба обычно достаточно включить PITR у провайдера БД и периодические off‑site‑бэкапы.

Простой пример: ежедневный дамп для локальной/dev БД

Даже если для продакшена вы полагаетесь на управляемую БД, для staging/dev иногда хочется иметь простой скрипт:

# scripts/backup.sh
#!/usr/bin/env bash
set -e
DATE=$(date +%F)
pg_dump "$DATABASE_URL" > "backups/backup-$DATE.sql"
echo "Backup created: backups/backup-$DATE.sql"

Запускать это можно из cron или GitHub Actions. Главное — не забыть, что бэкапы тоже нужно удалять по сроку жизни.

Поведение App при падении внешних сервисов

Бэкапы и PITR решают проблему «что делать, если всё совсем сломалось или данные испорчены». Но в бизнес‑реальности чаще случаются частичные сбои — упал внешний API, обрезало сеть, подвисла платёжка.

Когда OpenAI API или платёжка лежат, самая плохая стратегия — падать с голым 500 и бессмысленным stack trace в ответе. В идеале:

• backend возвращает структурированную ошибку вроде { error: "upstream_unavailable" };
• виджет отображает человеку понятное сообщение: «Сервис временно недоступен, попробуйте позже»;
• система не продолжает бомбить лежащий API бесконечными ретраями (паттерны Circuit Breaker и пр. мы подробнее посмотрим в модуле про устойчивость).

Пример обработчика MCP‑tool, который учитывает внешнюю ошибку:

// mcp/tools/createGiftIdea.ts
export async function createGiftIdea(args: Input): Promise<Output> {
  try {
    return await callOpenAiModel(args);
  } catch (err) {
    await logAudit({
      actor: { userId: args.userId ?? null, client: "chatgpt-app" },
      action: "giftidea.generate",
      outcome: { status: "failure", reason: "openai_unavailable" },
    });
    throw new Error("UPSTREAM_UNAVAILABLE");
  }
}

Дальше ваша прослойка между MCP и виджетом уже знает, как аккуратно показать эту ошибку в UI.

Проверка восстановления: бэкап без restore — просто файл

Классический анти‑паттерн: бэкап делается ежедневно, все довольны… пока не выясняется, что их невозможно восстановить (формат изменился, ключ потерян, место не хватило).

Минимальный план:

• периодически (например, раз в месяц) поднимать staging‑окружение из бэкапа;
• проходить базовые сценарии: логин, создание заказа, работа App;
• убеждаться, что время восстановления и потеря данных укладываются в ваши RTO/RPO.

Вместо курса по «религии DevOps» в рамках этой лекции достаточно понять: процессы резервного копирования — часть архитектуры App, а не «что‑то, что сделает кто‑то там в облаке».

6. Визуализация: жизненный цикл данных и событий

Чтобы всё это было не только в виде слов, нарисуем две простые схемы.

Жизненный цикл данных пользователя

flowchart TD
  A["Создание данных<br/>(регистрация, заказ)"] --> B["Хранение и использование<br/>(prod DB)"]
  B --> C["Архив/агрегация<br/>(анонимные метрики)"]
  B --> D[Запрос на удаление]
  D --> E[Удаление/анонимизация<br/>в prod DB]
  E --> F["Истечение срока жизни бэкапов<br/>(retention)"]
    

Главная идея: жизненный цикл данных не заканчивается на прод‑БД — он продолжается и в бэкапах.

Поток аудита для опасного действия

sequenceDiagram
  participant User as Пользователь
  participant ChatGPT as ChatGPT
  participant App as Ваш backend/MCP
  participant DB as База
  participant Audit as Audit storage

  User->>ChatGPT: "Отмени заказ #123"
  ChatGPT->>App: callTool cancel_order
  App->>DB: UPDATE orders SET status='canceled'
  App->>Audit: INSERT audit_event {actor, action, resource, outcome}
  App-->>ChatGPT: Результат операции
  ChatGPT-->>User: Сообщение о результате
    

7. Типичные ошибки в audit & lifecycle

Ошибка №1: Смешивание audit‑логов и обычных логов.
Когда все сообщения попадают в один общий logs‑index, через полгода никто не отличит «пользователь изменил роль администратора» от «у нас опять null reference». В audit должны быть структурированные события бизнес‑уровня (см. раздел про структуру события аудита) и отдельное хранилище с ограниченным доступом.

Ошибка №2: Логирование PII в аудите и debug‑логах.
Полный e‑mail, телефон, адрес доставки, последние четыре цифры карты — всё это часто случайно оказывается в логах. Это повышает риск утечки и противоречит рекомендациям по приватности. Вместо этого логируйте идентификаторы и замаскированные значения.

Ошибка №3: Отсутствие политики retention — «храним всё всегда».
На этапе MVP это кажется «ну и ладно», а через год ваши таблицы вырастают до чудовищных размеров, и любой запрос в аналитику превращается в DDoS самой БД. Плюс вы нарушаете принцип минимизации, заложенный в современных законах о данных. Минимальные TTL по типам данных должны быть продуманы, а чистка — автоматизирована.

Ошибка №4: «Удаление по запросу» == DELETE FROM users.
Если вы просто удалили строку пользователя, но оставили его PII в заказах, сессиях и логах, вы по сути никого не удалили. Корректный подход — транзакционно пройтись по всем связанным сущностям, а где нельзя удалить — анонимизировать. И не забыть залогировать сам факт удаления как audit‑событие.

Ошибка №5: Игнорирование бэкапов при удалении данных.
Удалили пользователя в проде — хорошо, но его данные ещё год живут в старых snapshots. При восстановлении из них всё «воскресает», и вы снова нарушаете свои же обещания пользователю и в Privacy Policy. Нужно либо ограничивать срок жизни бэкапов, либо иметь процедуру повторного применения удалений после восстановления.

Ошибка №6: «У нас включены бэкапы, значит всё хорошо», но никто не пробовал восстановиться.
Бэкап, который ни разу не проверяли на restore, — это просто дорогой файл. Без периодической проверки восстановления вы не знаете ни фактического RTO/RPO, ни того, работает ли вообще ваш DR‑план. Минимум — регулярный тестовый подъём staging из бэкапа по чек‑листу.

Ошибка №7: Несоответствие между документацией и реальностью.
В Privacy Policy вы пишете, что храните логи 30 дней и удаляете данные по запросу, а в коде всё остаётся навсегда. Магазин ChatGPT, enterprise‑клиенты и аудиторы легко это обнаружат вопросами вроде «покажите таблицу retention» и «продемонстрируйте удаление конкретного пользователя». Лучше сначала сделать, потом написать.