Безопасность SLAtech Vantage: как она устроена и где её пределы

SLAtech Vantage хранит данные многих организаций в одной базе и разделяет их фильтром, который применяется к каждому запросу. Вход идёт по одноразовому коду без паролей, ключи подключённых систем зашифрованы, персональные данные заменяются метками до отправки текста в языковую модель, а заказчик сам читает журнал доступа к данным своего проекта. Ниже каждый механизм описан так, как он сделан в коде, и рядом сказано, чего он не закрывает.

Кто что видит: организации, проекты, участия

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

• Доступ выводится из участия. Организация участвует в проекте как заказчик или как исполнитель. Поля доступа, которое кто-то заполняет вручную, нет: нет действующего участия, нет данных. Закончившееся участие ничего не удаляет, но доступ прекращает.
• Без входа видно пустоту. Запрос без аутентификации получает пустой набор проектов, а не "всё".
• Исполнитель видит свои задачи. Задача видна исполнителю, только если на неё назначена его организация. Новый исполнитель на проекте получает знания о проекте, но не переписку и не ставки прежнего.
• Права пересобираются. Список проектов хранится в билете входа и периодически пересобирается из участий, по умолчанию раз в 30 минут. Поэтому снятое участие перестаёт действовать не в ту же секунду.

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

Вход: одноразовый код вместо пароля

Паролей в системе нет, поэтому нечего подбирать, использовать повторно или терять при утечке чужой базы. Человек вводит адрес почты, и если учётная запись существует, на адрес приходит 6-значный код, действующий 10 минут. На незарегистрированный адрес экран отвечает точно так же, а письмо не отправляется.

• В базе хранится хеш кода, а не сам код. Код одноразовый: после входа он погашен.
• На код даётся 5 попыток. Попытка списывается одним условным запросом ещё до сравнения, поэтому параллельные запросы лимит не обходят.
• На один адрес: не больше 5 кодов в час и не чаще одного раза в 30 секунд.
• Сетевой адрес, с которого ушло 10 запросов кода и ни один не подтверждён, блокируется, пока с последнего запроса не пройдёт час. Верный код обнуляет счётчик, поэтому офис, который выходит в сеть с одного адреса, не блокируется.
• Сеанс живёт 7 дней и продлевается, пока человек работает. Токены приглашений, как и коды, хранятся хешем.

Счётчик сетевых адресов хранится в памяти процесса и сбрасывается при его перезапуске. Лимиты на адрес почты от этого не зависят: они хранятся в базе.

Права внутри организации и что остаётся внутренним

Владелец организации выдаёт права каждому человеку отдельно: деньги (ставки и суммы, по умолчанию выключено), отчёты и создание задач. Сам владелец организации деньги видит всегда.

• Кто без права на деньги, тот не видит сумм ни на экранах, ни в журнале доступа: строка события остаётся, значения из неё убираются. В тексте писем и в ответах чата для него скрываются числа, рядом с которыми стоит валюта или слово о цене.
• Внутренние заметки и внутреннее решение по задаче заказчику не показываются ни на экране, ни в ответах чата. Для заказчика пишется отдельное описание сделанного.
• Внутренняя разбивка часов исполнителя не попадает в клиентский портал, PDF, Excel и месячный отчёт. Это держит автоматический тест: если поле появится в данных, которые идут заказчику, тест упадёт до выпуска.

Скрытие сумм в тексте опирается на шаблон "число рядом с валютой или словом о цене". Фраза без числа, например "по обычной ставке", не скрывается.

Что уходит в языковую модель и как это маскируется

Чат, поиск по проекту и часть анализа работают через внешнюю языковую модель. Перед отправкой текст маскируется: персональные данные заменяются метками, модель видит только метки, а настоящие значения подставляются в ответ уже у нас. Пользователь видит настоящие данные, метки существуют только на границе с моделью.

• Что заменяется: адреса почты; израильские номера телефонов; номера удостоверений личности, компаний и предпринимателей, прошедшие проверку контрольной цифры; номера паспортов рядом со словом "паспорт" на иврите; имена людей из словаря имён и из карточек контактов проекта.
• Секреты удаляются безвозвратно. Пароли, ключи API, токены и строки подключения, записанные в тексте, в том числе внутри адресов ссылок, заменяются меткой, которую нельзя развернуть обратно ни модели, ни нам.
• У каждого проекта свой реестр меток. Настоящие значения за метками хранятся зашифрованными. Обратная подстановка идёт только по карте текущего запроса, поэтому метку из чужого ответа развернуть нельзя. Строки в форме наших меток, введённые в чат, вырезаются до обработки.
• Поисковый индекс строится по замаскированному тексту. Для индекса в модель уходит тот же текст с метками.
• Распознавание текста на сканах выполняется на нашем сервере, а не во внешнем сервисе, чтобы скан документа не уходил наружу ради распознавания.

Маскирование вызывается в каждом месте, где код обращается к модели. Автоматический тест обходит все такие места и падает, если какое-то из них не маскирует текст и при этом не внесено в список исключений с письменной причиной. Тест доказывает, что о маскировании не забыли, но не доказывает, что оно поймало всё.

Чего маскирование не закрывает

Маскирование построено на шаблонах и словаре, и у него есть известные пределы:

• Имя, которого нет ни в словаре, ни в карточках контактов, может уйти в модель открытым.
• Имена действующих сотрудников и подрядчиков из карточек контактов проекта не маскируются, если написаны полностью или одним именем: модели нужно понимать, кто чем занят. Фамилия отдельно маскируется.
• ТЗ, загруженное для оценки часов, и текст, по которому собирается ТЗ, уходят в модель как есть, вместе с картинками. Персональные данные в такие документы лучше не класть.
• Чтобы пополнять словарь имён, в модель отправляются отдельные слова без окружающего текста, и модель решает, имя это или обычное слово.
• Анализ кода задачи там, где он включён, читает копию репозитория с правами только на чтение и поиск. Сам код не маскируется, маскируется только текст задачи.

Ключи подключённых систем и что мы пишем обратно

Чтобы забирать задачи, часы, код и почту, SLAtech Vantage нужен доступ к вашей системе: токен Jira или GitHub, ключ API Freshservice, разрешение Google или Microsoft на чтение почтового ящика.

• Ключ шифруется перед записью в базу. У каждого вида ключей свой ключ шифрования, поэтому раскрытие одного вида не открывает остальные. Ключи шифрования хранятся вне базы данных.
• После сохранения ключ не возвращается в интерфейс и не пишется в журналы сервера.
• Ключ принадлежит человеку, который его подключил, и чужой ключ вместо него не подставляется. При удалении подключения зашифрованный ключ удаляется вместе с ним.
• Почта подключается с правом только на чтение (gmail.readonly, Mail.Read). Задачи, код, ошибки и часы только читаются.

Во внешнюю систему пишет одно подключение, Freshservice: смена статуса заявки и публичный ответ по ней, когда исполнитель делает это из карточки задачи. В репозиторий, Jira и трекеры ошибок SLAtech Vantage ничего не записывает.

Журнал доступа: заказчик читает его в своём портале

В клиентском портале есть пункт "Журнал доступа". Там заказчик видит, кто, из какой организации и когда трогал данные его проекта. Записываются события двух видов:

• Изменения: создано, изменено, удалено. Для изменения записано, какие поля поменялись и на что. Запись делается сама при сохранении в базу, а не вызовом из каждого экрана, поэтому новый экран попадает в журнал без доработки.
• Вынос наружу: скачанный файл (ТЗ и файлы к нему, предложение, вложение задачи, письма или переписки, файл базы знаний), выгруженный месячный отчёт, выданная публичная ссылка на предложение.

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

Пределы. Просмотры экранов не записываются. Фоновые процессы, за которыми нет человека, не записываются. Больше 20 однотипных объектов за одно сохранение сворачиваются в одну строку со счётчиком. Массовые правки, которые идут в обход обычного сохранения, журнал не видит. Сотрудник SLAtech, который заходит в проект как оператор платформы, а не как исполнитель этого проекта, в журнал не попадает. Портал показывает последние 200 записей. Записи хранятся семь лет.

Файлы, сроки хранения и журналы сервера

• Файлы (вложения писем, файлы задач и ТЗ, база знаний) лежат в закрытом объектном хранилище без публичных адресов. Скачивание идёт через приложение после проверки доступа, и скачивание вошедшим пользователем записывается в журнал доступа.
• Журнал доступа хранится семь лет: в течение этого срока в Израиле ещё можно подать иск по обязательству. Срок настраивается.
• Журнал действий в портале (входы заказчика, просмотры страниц и отчётов, выгрузки) хранится 12 месяцев и чистится ежедневной задачей.
• Вопросы к чату и ответы сохраняются в журнале чата без автоматического удаления.
• Журналы сервера ротируются по дням и по размеру, хранятся последние 20 файлов. Отчёты о сбоях уходят во внешний сервис мониторинга ошибок без адресов почты, кук и тела запроса, а из адреса запроса вырезаются секреты.
• Данные проекта по сроку автоматически не удаляются. Задача, удалённая в интерфейсе, уходит в архив, а не стирается из базы.

Соединение, заголовки и чего у нас нет

• Сайт и приложение работают только по HTTPS: запрос по HTTP перенаправляется, а заголовок HSTS сроком на год не даёт браузеру открыть сайт без шифрования.
• Ответы несут X-Content-Type-Options: nosniff и Referrer-Policy: strict-origin-when-cross-origin, а встраивать страницы во фреймы чужих сайтов запрещено.
• На страницах, которые открываются по ссылке для согласования документа, политика безопасности содержимого (CSP) действует и блокирует чужие скрипты. На остальных страницах она пока работает в режиме отчёта: нарушения собираются, но не блокируются.

SLAtech Vantage построен с учётом израильского закона о защите частной жизни, включая поправку 13: меньше данных уходит наружу, клиенты разделены, и фиксируется, что делалось с данными. Это не заявление о соответствии закону.

Сертификатов ISO 27001, SOC 2 и других у нас нет, и эта страница их не заявляет. Внешнего теста на проникновение мы здесь тоже не заявляем.

Частые вопросы