Безопасность лежит в основе того, как мы создаём наш продукт. На этой странице описано то, что действительно соответствует нашей архитектуре и практикам сегодня, — это не маркетинговый чек-лист. Там, где мы что-то ещё не завершили (формальный аудит, сертификацию), мы прямо об этом говорим, а не намекаем на обратное.
Здравоохранение и HIPAA
Сегодня продукты Divinci не одобрены для работы с защищённой медицинской информацией (PHI). Ни одно Business Associate Agreement не распространяется на платформу Divinci, поэтому не следует передавать в неё PHI.
Мы готовим отдельное предложение для здравоохранения: выделенную среду выполнения чата, размещённую в собственном проекте Google Cloud и отделённую от остальной платформы Divinci. Она спроектирована так, чтобы не хранить стенограммы разговоров. Business Associate Agreement мы пока не подписываем.
Чем это не является: сертификацией соответствия HIPAA. Государственного сертификата HIPAA не существует, и мы не заявляем о соответствии HIPAA. Соответствие складывается из технических мер защиты, письменных политик и подписанных Business Associate Agreement с каждым поставщиком на пути данных, оцениваемых применительно к каждым отношениям с клиентом. Мы приняли письменные политики, которые ещё проходят юридическую проверку, и сообщим здесь, когда это изменится.
Защита данных
Шифрование
- При передаче: TLS повсеместно — между клиентами, нашей граничной сетью и нашей инфраструктурой источника.
- При хранении: шифрование на уровне провайдера для нашего основного хранилища данных и объектного хранилища, плюс отдельный слой шифрования на уровне полей для обозначенных чувствительных полей.
- Управление секретами: учётные данные и API-ключи управляются через централизованный менеджер секретов, а не прописываются в коде и не хранятся в конфигурации открытым текстом. В продакшене настроен «отказ в безопасную сторону»: если сервис секретов недоступен, система не переходит молча на устаревшие учётные данные.
Минимизация данных
- К содержимому чатов можно применять необязательное маскирование PII (Microsoft Presidio) до его сохранения или передачи поставщику ИИ. Это обнаружение сущностей, а не определение обезличивания по HIPAA, и оно не делает продукт безопасным для работы с PHI.
- Согласно нашей политике, журналы содержат только метаданные: мы не записываем содержимое сообщений, адреса электронной почты или иные персональные данные в журналы приложений и в сообщения об ошибках.
Контроль доступа
- Аутентификация через Auth0.
- Ролевой контроль доступа (на уровне платформы) плюс права по каждому ресурсу (на уровне документа/рабочего пространства) — принцип наименьших привилегий по умолчанию.
- Журнал аудита с защитой от подделки: доступ к чувствительным записям фиксируется в журнале, связанном цепочкой хэшей, который спроектирован так, чтобы записи нельзя было незаметно изменить задним числом.
- Ежеквартальные проверки доступа и конфигурации продакшен-сервисов.
Безопасность приложения
- Защита от XSS на границе отрисовки: содержимое, созданное пользователями и ИИ, очищается (DOMPurify) везде, где оно отрисовывается как HTML; внедрение «сырого» HTML из недоверенных источников не допускается.
- Тестирование авторизации: мы проводим собственное тестирование безопасности — как с помощью ИИ, так и вручную — на staging- и продакшен-средах, включая проверки авторизации/IDOR под учётной записью. Это (пока) не постоянная программа стороннего тестирования на проникновение, и мы не станем заявлять о её наличии, пока она действительно не появится.
- Проверка зависимостей и код-ревью: стандартное код-ревью для всех изменений; обновления зависимостей отслеживаются нашими обычными инструментами сборки.
Доступность и мониторинг
- Синтетический мониторинг клиентских эндпоинтов с оповещением дежурного через PagerDuty в течение нескольких минут после реального сбоя, а не только при ошибках сервера, — проверки с верификацией содержимого ответа, а не просто «вернулся ли код 200».
- Мультирегиональная инфраструктура (граничная сеть Cloudflare + источник на Google Cloud) с автоматическими резервными копиями нашего основного хранилища данных.
- Мы в настоящее время не публикуем договорное соглашение об уровне обслуживания (SLA) по доступности. Если ваш сценарий использования этого требует — спросите нас, и мы обсудим, что реалистично для вашего развёртывания.
Реагирование на инциденты
У нас есть документированный процесс реагирования на инциденты: обнаружение и классификация, локализация, честная оценка того, дорастает ли инцидент до уровня утечки, подлежащей уведомлению, устранение последствий и разбор без поиска виноватых, результаты которого возвращаются в то, что мы отслеживаем в дальнейшем. Если вы — клиент, с которым у нас заключено соглашение с деловым партнёром (Business Associate Agreement), то именно это соглашение определяет наши обязательства по уведомлению вас; действуют его условия, а не текст этой страницы.
Чтобы сообщить о проблеме безопасности или о предполагаемой уязвимости, напишите на security@divinci.ai. В настоящее время у нас нет формальной программы вознаграждения за найденные уязвимости (bug bounty); при этом мы относимся к сообщениям серьёзно и будем добросовестно с вами взаимодействовать.
На каком этапе мы находимся с формальными сертификациями
Скажем об этом прямо, поскольку многие страницы о безопасности этого не делают:
- HIPAA: у нас нет сертификации HIPAA, и мы не заявляем о соответствии. См. «Здравоохранение и HIPAA» выше.
- SOC 2: ещё не начат. Он есть в нашей дорожной карте; мы обновим эту страницу, когда появится что-то реальное, о чём можно сообщить, — но не раньше.
- ISO 27001, FedRAMP, PCI DSS: у нас нет этих сертификаций. Платежи по картам обрабатываются через Stripe; Divinci не хранит данные держателей карт напрямую.
Мы предпочитаем заявлять здесь меньше, чем есть, и пользоваться доверием, чем заявлять больше, чем есть, и потом брать свои слова обратно.
Контакты
Вопросы по безопасности, сообщения об уязвимостях или вопросы соответствия требованиям в рамках конкретной сделки: security@divinci.ai