Безопасность платформы и порядок раскрытия уязвимостей

1. Принципы безопасности

1.1. Минимально необходимый доступ. Каждый компонент имеет только те права, которые ему нужны для работы. Партнёр видит обезличенные данные своей когорты; админ видит то, что необходимо для триажа; разработчики не имеют прямого доступа к продакшен-данным студентов.

1.2. Defence in depth. Не полагаемся на один слой. HTTPS на транспорте, JWT-аутентификация, rate-limit на формах, изоляция docker-контейнеров, sandbox-исполнение пользовательского кода.

1.3. Прозрачность по инцидентам. При инциденте, затрагивающем данные пользователей, уведомляем затронутых субъектов и уполномоченный орган в порядке, предусмотренном применимым правом (см. п. 6).

2. Защита данных в транзите и в покое

2.1. HTTPS обязателен на всех публичных эндпойнтах (`agentnine.io`, `learn.agentnine.io`, `app.agentnine.io`, `docs.agentnine.io`, `admin.agentnine.io`). HTTP-запросы редиректятся на HTTPS на уровне nginx; HSTS включён с `max-age=63072000` и `preload`-флагом.

2.2. Сертификаты Let's Encrypt с автоматическим обновлением через certbot. Поддерживаемые алгоритмы и cipher suites — современный TLS 1.2+ профиль ( ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-GCM-SHA384 и аналогичные).

2.3. База данных в покое хранится на дисках с шифрованием на уровне хостера. Бэкапы — gzip-архивы, ротация 7 дней (production data retention).

2.4. Секреты (JWT-secret, SMTP-пароли, API-ключи LLM-провайдеров) хранятся в `.env`-файле на проде, не попадают в репозиторий, не передаются клиентам, не логируются.

2.5. Cookies сессии устанавливаются с флагами `HttpOnly`, `Secure`, `SameSite=Lax`. JS-код не имеет доступа к session-токену — это блокирует XSS-эксфильтрацию.

3. Аутентификация и контроль доступа

3.1. Студенты входят через email magic-link (одноразовая ссылка, TTL 15 минут) либо Google OAuth. Пароли как факт не существуют — нет уязвимости утечки захэшированных паролей.

3.2. Админы входят отдельно через `admin.agentnine.io`. Доступ выдаётся вручную; список привилегированных аккаунтов аудируется.

3.3. Партнёры входят через выделенный magic-link на `learn.agentnine.io/partner/login` (отдельный scope от обычных юзеров).

3.4. Rate-limiting на endpoint-ах аутентификации и публичных формах: 5 попыток / 24 ч на IP-адрес. Отдельные счётчики на разные классы (auth / form / cert verify), чтобы спам в одну зону не блокировал другую.

4. Сообщить об уязвимости

4.1. В каких случаях писать:

• обход аутентификации, эскалация привилегий;
• SQL-injection, XSS, CSRF, открытые редиректы;
• раскрытие чужих персональных данных;
• проблемы с биллингом, обходы оплаты;
• некорректная атрибуция партнёра или подделка сертификата;
• SSRF, выход из sandbox-а пользовательского кода.

4.2. Адрес для отправки: security@agentnine.io.

4.3. Содержание сообщения. Описание уязвимости, шаги воспроизведения, потенциальное воздействие, ваше имя/handle для атрибуции (если хотите быть упомянуты в hall of fame — появится после первых отчётов).

4.4. Что мы делаем дальше:

• подтверждаем получение в течение 5 рабочих дней;
• триажируем критичность, фиксим в порядке приоритета;
• держим вас в курсе прогресса;
• после деплоя фикса — согласуем дату публикации (стандартное окно — 90 дней с даты получения отчёта).

4.5. Безопасные действия исследователя — мы не будем преследовать вас за добросовестное исследование, если вы:

• не получаете доступ к данным больше, чем нужно для PoC;
• не публикуете уязвимость до согласованного disclosure-окна;
• не модифицируете и не удаляете данные пользователей;
• не нарушаете доступность (DoS) сервиса;
• не атакуете третьих лиц через инфраструктуру Agent Nine.

5. Что мы НЕ принимаем как уязвимость

5.1. Чтобы не тратить время с обеих сторон — заранее перечислим типичные false positives, которые НЕ являются для нас уязвимостями:

• отсутствие SPF/DKIM/DMARC на доменах, не используемых для отправки почты;
• отсутствие rate-limit на эндпойнтах, где он не требуется по дизайну;
• self-XSS (требует, чтобы пользователь сам вставил payload);
• missing security headers (CSP, X-Frame-Options) на статических страницах без интерактива;
• информация о версиях ПО в HTTP-заголовках;
• уязвимости в third-party сервисах, которыми мы не можем управлять;
• социальная инженерия наших сотрудников;
• физический доступ к нашей инфраструктуре.

6. Инциденты и уведомления

6.1. При обнаружении инцидента, потенциально затрагивающего персональные данные пользователей:

• фиксируем факт инцидента, проводим первичную локализацию (ожидаемое время — 24 часа);
• проводим расследование (объём затронутых данных, вектор, причина);
• уведомляем затронутых субъектов и уполномоченный орган в области защиты ПДн в порядке и сроки, предусмотренные применимым правом;
• публикуем post-mortem (с разрешения заявителя, без раскрытия чувствительных деталей).

7. Контакты

7.1. Сообщения об уязвимостях: security@agentnine.io

7.2. PGP-ключ для шифрования отчётов — будет опубликован после регистрации юр. лица. До этого — чувствительные детали можно отправить простым текстом, мы соблюдаем NDA по умолчанию.

7.3. Общие вопросы по приватности и защите данных: privacy@agentnine.io (см. также Политику конфиденциальности).

7.4. Машиночитаемый файл /.well-known/security.txt (RFC 9116) опубликован и автоматически обновляется при изменениях этой страницы.