Безопасность

Как устроена защита данных в Klinersha, что работает сейчас, и что мы планируем сделать в ближайших релизах.

Изоляция данных организаций

В бета-версии: полная изоляция на уровне базы — в плане

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

  1. RLS на уровне PostgreSQL включён на четырёх таблицах интеграции — там, где идёт обмен с внешними системами и риск утечки максимален.
  2. Фильтры приложения в Python-коде FastAPI добавляютorganization_idк каждому запросу. Это покрывает остальные таблицы, где RLS пока не настроен.

Двухслойная схема работает, но это инженерный компромисс: приложение должно не забыть добавить фильтр. Полная изоляция на уровне базы — это когда RLS покрывает все таблицы, и приложение физически не может прочитать чужие данные, даже если ошибётся.

Известное ограничение (урок пилота 19.08)

В ходе пилота 19 августа выяснилось: вызовset_tenant_contextв PostgreSQL терял контекст послеcommit, и последующий запрос с RLS возвращал ноль строк без ошибки.

Это типичная ловушка: ошибка выглядит как «пустой результат», а не как исключение. Именно поэтому мы не утверждаем «изоляция на уровне базы работает» — пока RLS не покрывает все таблицы и не защищён тестами на каждом слое, остаются серые зоны.

План закрытия

Применяемmigrations/003_harden_rls_policies.sql— расширение RLS на все таблицы организаций. Перед применением на проде каждый запрос проходит проверку на PostgreSQL, а не на SQLite в тестах, иначе урок 19.08 повторится.

Архитектурное обоснование — вarchitecture/sales-blockers/03-marketing-truth-and-trust.mdиarchitecture/sales-blockers/01-billing-and-legal.md.

Шифрование и резервные копии

Шифрование данных

Соединения с сервером идут по TLS. Пароли и чувствительные поля хранятся в базе в виде хеша, а не открытым текстом. Данные на диске сервера защищены шифрованием диска.

Ежедневные резервные копии

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

Доступ и роли

В Klinersha три типа доступа к организации: собственник, менеджер и клинер/горничная. Каждая роль видит только то, что нужно для работы: горничная — задачи и чек-листы, менеджер — задачи, отчёты и сотрудников, собственник — всё плюс настройки организации и биллинг.

На уровне ручек FastAPI доступ проверяется единымbefore_request-хуком (по образцу fanoteli), а не декоратором на каждом роуте — это закрывает класс багов «забыли поставить проверку».

Сессия закрывается по таймауту. Закрытый доступ к интерфейсу администратора — через отдельный путь с дополнительной авторизацией.

Соответствие требованиям

152-ФЗ «О персональных данных»в плане

Заявление о полном соответствии 152-ФЗ появится на сайте, когда выполнены три вещи:

  1. опубликована политика обработки персональных данных
  2. форма регистрации содержит согласие на обработку
  3. подано уведомление в РКН

Сейчас заявление о соответствии снято с витрины. Юридическая часть — в работе (блокер 01 из серии sales-blockers).

Что мы НЕ делаем

  • Не публикуем фейковых отзывов и рейтингов в JSON-LD (агрегат-рейтинг был — снят).
  • Не выдумываем «кейсы клиентов» с процентами: раздел переименован в «Сценарии использования» и не привязан к реальным или выдуманным организациям.
  • Не обещаем готовых коннекторов к PMS (Bnovo, Ostrovok и т.п.), пока их нет в коде.

Остались вопросы по безопасности?

Напишите в Telegram — ответим в течение рабочего дня и пришлём подробности по архитектуре.

Начать бесплатноСвязаться с нами