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

Безопасность лежит в основе того, как мы создаём наш продукт. На этой странице описано то, что действительно соответствует нашей архитектуре и практикам сегодня, — это не маркетинговый чек-лист. Там, где мы что-то ещё не завершили (формальный аудит, сертификацию), мы прямо об этом говорим, а не намекаем на обратное.

Архитектура, подготовленная к требованиям HIPAA

Мы по умолчанию встроили в платформу технические меры защиты, необходимые для рабочих процессов, подпадающих под HIPAA:

Обезличивание до сохранения или обработки ИИ. Содержимое чата может направляться через этап автоматического удаления персональных и медицинских данных (PII/PHI) — с помощью Microsoft Presidio, включая модель, настроенную на клинические тексты для медицинских контекстов, — до того, как оно попадёт в нашу базу данных, к нашим провайдерам ИИ или в поиск/извлечение. При этом распознаются все 18 категорий идентификаторов из метода Safe Harbor («безопасной гавани») в HIPAA. Этот этап работает по принципу «отказ в безопасную сторону»: если удаление данных не может быть выполнено, сообщение отклоняется, а не сохраняется молча в неочищенном виде.
Журналирование обращений с защитой от подделки. Доступ к чувствительным записям фиксируется в журнале со сцеплением хешей, устроенном так, чтобы записи нельзя было незаметно изменить задним числом.
Контроль доступа на уровне ролей и на уровне ресурсов. И общеплатформенные роли, и права по каждому ресурсу определяют, кто что может видеть.
Шифрование при передаче и при хранении, с возможностью шифрования на уровне отдельных полей для обозначенных чувствительных данных.

Чем это не является: это не сертификация соответствия HIPAA. Государственного сертификата HIPAA не существует — соответствие складывается из технических мер защиты (см. выше), письменных административных политик и подписанных соглашений с деловым партнёром (Business Associate Agreement, BAA) с каждым поставщиком на пути данных, и оценивается индивидуально для конкретных отношений с клиентом. Если вам необходимо обрабатывать с нами защищённую медицинскую информацию (PHI) в рамках соглашения с деловым партнёром (Business Associate Agreement), свяжитесь с нами — мы разберём вместе, что потребуется для вашего конкретного сценария использования.

Защита данных

Шифрование

При передаче: TLS повсеместно — между клиентами, нашей граничной сетью и нашей инфраструктурой источника.
При хранении: шифрование на уровне провайдера для нашего основного хранилища данных и объектного хранилища, плюс отдельный слой шифрования на уровне полей для обозначенных чувствительных полей.
Управление секретами: учётные данные и API-ключи управляются через централизованный менеджер секретов, а не прописываются в коде и не хранятся в конфигурации открытым текстом. В продакшене настроен «отказ в безопасную сторону»: если сервис секретов недоступен, система не переходит молча на устаревшие учётные данные.

Минимизация данных

Обезличивание (см. выше) означает, что исходные PII/PHI отбрасываются, а не сохраняются, везде, где работает этот конвейер, — это минимально возможный объём данных под угрозой, если какая-либо нижестоящая система будет скомпрометирована.
Согласно нашей политике, журналы содержат только метаданные: мы не записываем содержимое сообщений, адреса электронной почты или иные персональные данные в журналы приложений и в сообщения об ошибках.

Контроль доступа

Аутентификация через Auth0.
Ролевой контроль доступа (на уровне платформы) плюс права по каждому ресурсу (на уровне документа/рабочего пространства) — принцип наименьших привилегий по умолчанию.
Ежеквартальные проверки доступа и конфигурации продакшен-сервисов.

Безопасность приложения

Защита от XSS на границе отрисовки: содержимое, созданное пользователями и ИИ, очищается (DOMPurify) везде, где оно отрисовывается как HTML; внедрение «сырого» HTML из недоверенных источников не допускается.
Тестирование авторизации: мы проводим собственное тестирование безопасности — как с помощью ИИ, так и вручную — на staging- и продакшен-средах, включая проверки авторизации/IDOR под учётной записью. Это (пока) не постоянная программа стороннего тестирования на проникновение, и мы не станем заявлять о её наличии, пока она действительно не появится.
Проверка зависимостей и код-ревью: стандартное код-ревью для всех изменений; обновления зависимостей отслеживаются нашими обычными инструментами сборки.

Доступность и мониторинг

Синтетический мониторинг клиентских эндпоинтов с оповещением дежурного через PagerDuty в течение нескольких минут после реального сбоя, а не только при ошибках сервера, — проверки с верификацией содержимого ответа, а не просто «вернулся ли код 200».
Мультирегиональная инфраструктура (граничная сеть Cloudflare + источник на Google Cloud) с автоматическими резервными копиями нашего основного хранилища данных.
Мы в настоящее время не публикуем договорное соглашение об уровне обслуживания (SLA) по доступности. Если ваш сценарий использования этого требует — спросите нас, и мы обсудим, что реалистично для вашего развёртывания.

Реагирование на инциденты

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

Чтобы сообщить о проблеме безопасности или о предполагаемой уязвимости, напишите на security@divinci.ai. В настоящее время у нас нет формальной программы вознаграждения за найденные уязвимости (bug bounty); при этом мы относимся к сообщениям серьёзно и будем добросовестно с вами взаимодействовать.

На каком этапе мы находимся с формальными сертификациями

Скажем об этом прямо, поскольку многие страницы о безопасности этого не делают:

HIPAA: см. раздел «Архитектура, подготовленная к требованиям HIPAA» выше. Применимо ли соглашение с деловым партнёром (Business Associate Agreement), зависит от ваших конкретных отношений с нами — мы оцениваем это по каждому клиенту отдельно, а не заявляем огульно.
SOC 2: ещё не начат. Он есть в нашей дорожной карте; мы обновим эту страницу, когда появится что-то реальное, о чём можно сообщить, — но не раньше.
ISO 27001, FedRAMP, PCI DSS: у нас нет этих сертификаций. Платежи по картам обрабатываются через Stripe; Divinci не хранит данные держателей карт напрямую.

Мы предпочитаем заявлять здесь меньше, чем есть, и пользоваться доверием, чем заявлять больше, чем есть, и потом брать свои слова обратно.

Контакты

Вопросы по безопасности, сообщения об уязвимостях или вопросы соответствия требованиям в рамках конкретной сделки: security@divinci.ai