Технический документ по безопасности и архитектуре

1. Архитектура и изоляция арендаторов

Платформа работает на одной управляемой базе данных PostgreSQL в мультиарендном режиме. Каждый клиент (площадка) — это отдельная организация, и все операционные данные помечаются идентификатором организации.

Изоляция двухуровневая. Основной уровень — на уровне приложения: каждый запрос данных обязательно фильтруется по идентификатору организации. Эта дисциплина поддерживается диагностическими инструментами (предупреждение статического анализа и сканирование области арендатора), которые делают риск запроса без фильтра видимым на этапе разработки. Второй уровень — политики безопасности на уровне строк (RLS) в базе данных, обеспечивающие дополнительный рубеж защиты для аутентифицированных путей доступа.

Уровень холдинга (для многоплощадочных корпоративных клиентов) — это отдельный уровень группировки над организациями. Доступ администратора холдинга к нескольким площадкам никогда не берётся из идентификатора, присланного клиентом, а выводится из проверенного на сервере членства в холдинге. Администратор может читать только площадки своего холдинга; право записи внутри площадки отделено от права чтения.

2. Идентификация и авторизация

Аутентификация обеспечивается через Supabase Auth (сессии на основе JWT). Ролевая модель отраслевая и детальная: Патрон (владелец бизнеса), Консультант Кайдзен, Сотрудник; также есть роль администратора холдинга для многоплощадочного доступа и роль супер-администратора для эксплуатации платформы.

Каждая серверная операция повторно проверяет роль пользователя и членство в организации из сессии; решения об авторизации никогда не оставляются только на стороне клиента. Для предотвращения повышения привилегий шлюзы доступа централизованы на сервере.

3. Шифрование

Данные при передаче (in transit): все соединения клиент-сервер и сервер-база данных шифруются по TLS.

Данные при хранении (at rest): данные защищены дисковым шифрованием управляемой инфраструктуры PostgreSQL (AES-256 на уровне провайдера). Резервные копии и объекты хранилища также подлежат шифрованию провайдера.

Секретные ключи (Gemini API, сервисный ключ базы данных, ключи платёжных и почтовых провайдеров) хранятся только на стороне сервера и никогда не включаются в клиентский бандл. Это обеспечивается проверкой сканирования секретов в CI.

4. Поток данных, размещение и соответствие (KVKK / GDPR)

Обрабатываемые персональные данные минимальны по замыслу: идентификационные данные сотрудников (имя, e-mail, роль) и операционные данные (предложения кайдзен, документы стандартной работы, KPI). Специальные категории персональных данных не собираются; кроме того, есть серверный уровень защиты для обнаружения чувствительных данных во вводе пользователя.

Размещение данных (регион), сроки хранения, права на удаление и список субобработчиков подробно определяются в Соглашении об обработке данных (DPA). Международные передачи и необходимые договорные гарантии (например, Стандартные договорные положения) рассматриваются в рамках договора с клиентом.

Функции ИИ отправляют ввод пользователя в Gemini API для обработки; эти отношения субобработки явно указаны в таблице субобработчиков DPA.

5. Обработка данных ИИ

ИИ-ассистент (Сэнсэй) и связанные функции работают через Google Gemini API. Контекст, отправляемый ИИ, ограничен собственными данными соответствующей организации; система инструктирует модель «иметь доступ только к данным этой организации» и применяет правила прозрачности источников.

В корпоративном дополнении Custom AI прошлые записи кайдзен площадки хранятся в виде векторных эмбеддингов в изолированной базе знаний, специфичной для организации; эта база доступна только ассистенту соответствующей организации и закрыта для межарендного доступа.

6. Резервное копирование и непрерывность

Управляемая инфраструктура PostgreSQL обеспечивает автоматическое ежедневное резервное копирование (базовый уровень). Для корпоративной отказоустойчивости разработан отдельный внешний (off-site) механизм резервного копирования, при котором база данных регулярно экспортируется в независимое объектное хранилище; этот механизм активируется по требованиям клиента.

Дополнительные опции, такие как цели восстановления (RPO/RTO) и восстановление на момент времени (PITR), рассматриваются в рамках корпоративного договора.

7. Мониторинг и реагирование на инциденты

Состояние системы постоянно отслеживается через мониторинг ошибок (Sentry) и продуктовую аналитику (PostHog). Кроме того, чувствительные действия записываются в журналы аудита: журнал аудита миграций, журнал аудита супер-администратора и журнал аудита доступа.

При инцидентах безопасности следуют определённому процессу для определения масштаба, уведомления затронутых сторон и корректирующих мер. Сроки и процедура уведомления о нарушениях детализированы в документе DPA.

8. Безопасность разработки и развёртывания

Каждое изменение, идущее в продакшн, проходит единый локальный шлюз проверки: проверка типов, статический анализ (lint), автоматические тесты и пороги покрытия кода, проверки целостности дизайн-системы и сканирование секретов. Эти проверки блокирующие; при сбое изменение не может быть опубликовано. Дополнительно сканирование области арендатора как диагностическая (report-only) проверка выявляет отклонения запросов без фильтра для последующего анализа.

Для безопасности зависимостей выполняется автоматический аудит, а обновления зависимостей проходят контролируемый поток.

Субобработчики

Следующие субобработчики используются при эксплуатации платформы. Регион и договорные детали определяются в DPA.

Соглашение об обработке данных (DPA)

Вы можете ознакомиться с нашим шаблоном Соглашения об обработке данных, соответствующим KVKK и GDPR, или запросить его.

Для дополнительной оценки безопасности, аудита или запросов RFP напишите основателю через форму корпоративного запроса.