Политика информационной безопасности

На этой странице описываются сертификации Didit, технические и организационные меры контроля, применяемые Didit, а также доступные артефакты доверия для клиентов, потенциальных клиентов, регуляторов и аудиторов. Она пересматривается не реже одного раза в шесть месяцев.

• Контакт по вопросам безопасности: security@didit.me
• Сотрудник по защите данных: dpo@didit.me
• Страница статуса (в реальном времени): status.didit.me
• Пакет доверия (под NDA): электронная почта security@didit.me

1. Сертификации и аттестации

Для запроса любого из базовых отчетов или сертификатов отправьте электронное письмо на security@didit.me. Отчеты, ограниченные условиями их издателя (например, SOC 2 Type 1), предоставляются после подписания Соглашения о неразглашении (NDA) в тот же рабочий день.

2. Область применения

Настоящая политика охватывает весь персонал Didit (сотрудников, подрядчиков и уполномоченных третьих лиц), все производственные и корпоративные информационные системы Didit, а также клиентские Услуги, описанные в Условиях и положениях для бизнеса. Она поддерживается Заявлением о применимости, которое является основой системы управления Didit ISO/IEC 27001:2022.

3. Управление

• Система управления информационной безопасностью и конфиденциальностью, соответствующая стандартам ISO/IEC 27001:2022 и ISO/IEC 27701, с документированным Заявлением о применимости.
• Главный технический директор является назначенным исполнительным спонсором по информационной безопасности; Сотрудник по защите данных (dpo@didit.me) отвечает за управление программой конфиденциальности.
• Ежегодный внешний аудит безопасности независимыми аудиторами (надзор ISO 27001 и проверки SOC 2).
• Реестр рисков пересматривается и обновляется ежеквартально. Существенные риски передаются в комитет по управлению.
• Постоянное улучшение, каждый инцидент, результаты аудита и оценка рисков пополняют список корректирующих действий и следующее обновление политики.

4. Шифрование и управление ключами

• В состоянии покоя: AES-256 во всех производственных базах данных, объектных хранилищах и томах резервного копирования.
• При передаче: TLS 1.3 для каждого внешнего вызова API, веб-хука и сессии Бизнес-консоли. Более старые версии TLS и слабые шифры отключены. HTTP Strict Transport Security (HSTS) применяется на всем сайте и предварительно загружается.
• Управление ключами: AWS Key Management Service (KMS) хранит и ротирует ключи. Код приложения никогда не касается необработанного материала ключей. Ключи для тестовой и производственной среды полностью разделены.
• Хеширование: учетные данные клиентов хешируются с использованием стандартных адаптивных функций (bcrypt или эквивалент). Ключи API хранятся в виде односторонних хешей; необработанное значение показывается оператору только во время создания.

5. Идентификация, доступ и архитектура нулевого доверия

• Нулевое доверие по умолчанию, каждый запрос к каждой внутренней системе аутентифицируется и авторизуется. Нет неявного доверия, основанного на сетевом местоположении.
• Контроль доступа на основе ролей (RBAC) с принципом наименьших привилегий. Проверки доступа проводятся ежеквартально.
• Многофакторная аутентификация (MFA) обязательна для каждого сотрудника, каждой производственной системы, каждой облачной консоли и каждой учетной записи хостинга кода.
• Единый вход (SSO) для внутренних приложений, с аппаратным токеном MFA для привилегированных ролей.
• Доступ «точно в срок» (Just-in-Time) для производства: постоянный привилегированный доступ является исключением, а не правилом.
• Журналирование аудита, каждое привилегированное действие записывается в защищенный от подделки, однократно записываемый аудиторский конвейер, хранящийся не менее 12 месяцев.

6. Резидентность и разделение данных

• Европейский Союз по умолчанию. Производственные данные обрабатываются и хранятся в Европейском Союзе на Amazon Web Services. Резидентность в конкретном регионе или стране доступна по корпоративным контрактам, при условии наличия, для юрисдикций, регуляторы которых этого требуют.
• Разделение сред. Тестовая, промежуточная и производственная среды изолированы на уровнях сети, идентификации и управления ключами. Ни один человек или служба в одной среде не может читать данные в другой без явного, аудитируемого пути доступа.
• Разделение арендаторов. Многопользовательские данные логически разделены с использованием ключей шифрования для каждого арендатора, где это применимо. Межпользовательские запросы блокируются на уровне приложения и базы данных.

7. Жизненный цикл безопасной разработки (SDLC)

• Проверка кода требуется для каждого производственного изменения. Ни один инженер не может объединять непроверенный код в производство.
• Статический анализ безопасности приложений (SAST), сканирование зависимостей и анализ состава программного обеспечения (SCA) запускаются автоматически при каждом запросе на слияние.
• Сканирование контейнеров и инфраструктуры при каждой сборке и по регулярному расписанию для развернутых образов.
• Предпроизводственное тестирование безопасности для изменений с высоким воздействием (аутентификация, управление ключами, биометрические конвейеры, платежные потоки).
• Внутренние тесты на проникновение непрерывно; внешние тесты на проникновение не реже одного раза в год независимыми специалистами. Существенные обнаружения отслеживаются до закрытия по графику, привязанному к SLA.
• Программа вознаграждения за обнаружение ошибок / канал ответственного раскрытия, сообщайте о проблемах безопасности на security@didit.me.

8. Управление уязвимостями

• SLA по исправлению ошибок по степени серьезности: критические (в течение 72 часов после раскрытия поставщиком), высокие (в течение 7 дней), средние (в течение 30 дней), низкие (в течение 90 дней).
• Непрерывное сканирование уязвимостей по всей производственной инфраструктуре, контейнерам и зависимостям.
• Моделирование угроз для новых поверхностей продуктов, биометрических конвейеров и межсредовых интеграций.

9. Мониторинг, обнаружение и реагирование на инциденты

• Круглосуточный мониторинг каждой производственной системы с оповещением о доступности, ошибках и сигналах безопасности.
• Система управления информацией и событиями безопасности (SIEM) агрегирует и коррелирует события безопасности; аномальные паттерны передаются дежурным инженерам по безопасности.
• Документированный план реагирования на инциденты с назначенными ролями, деревом связи, матрицей серьезности и процессом пост-инцидентного анализа. План тестируется не реже одного раза в год с помощью настольных учений.
• Уведомление о нарушении персональных данных. Didit уведомляет затронутых клиентов без неоправданной задержки и в любом случае своевременно, чтобы клиенты могли выполнить свое собственное 72-часовое обязательство по уведомлению в соответствии со статьей 33 Общего регламента по защите данных (GDPR). Корпоративные клиенты получают назначенного инженера на связи и выделенный канал связи.
• Публичная страница статуса на status.didit.me, каждый производственный инцидент, каждый постмортем, вход не требуется.

10. Непрерывность бизнеса и аварийное восстановление

• Многозональное активное резервирование в каждом производственном регионе; автоматическое переключение для безстатусных служб.
• Резервные копии шифруются, географически разделены в пределах выбранной границы резидентности и тестируются по регулярному расписанию.
• Целевая точка восстановления (RPO) ≤ 1 час и Целевое время восстановления (RTO) ≤ 4 часа для основного API верификации и Бизнес-консоли.
• Тесты аварийного восстановления (DR) не реже одного раза в год.

11. Безопасность персонала

• Проверка биографических данных каждого сотрудника и каждого подрядчика, имеющего доступ к производственным или персональным данным, где это разрешено применимым законодательством.
• Соглашения о конфиденциальности при приеме на работу для каждого сотрудника и подрядчика.
• Обязательное обучение по безопасности и конфиденциальности при приеме на работу и ежегодно для каждого сотрудника. Целевое обучение (безопасное кодирование, обработка биометрических данных, борьба с мошенничеством, борьба с отмыванием денег) для тех ролей, которым это необходимо.
• Фишинговые симуляции по регулярному расписанию.
• Процесс приема / перемещения / увольнения отзывает доступ в течение 24 часов после изменения роли или увольнения.

12. Управление поставщиками и субпроцессорами

• Каждый субпроцессор оценивается на предмет рисков перед подключением и пересматривается не реже одного раза в год.
• Каждый субпроцессор подписывает Соглашение об обработке данных (DPA), налагающее обязательства по защите данных, существенно аналогичные тем, которые Didit несет перед своими клиентами.
• Текущий список субпроцессоров предоставляется клиентам и потенциальным клиентам по электронной почте после подписания Соглашения о неразглашении (NDA). Отправьте электронное письмо на security@didit.me, чтобы запросить его. Клиенты, подписанные на уведомления об изменениях субпроцессоров, получают уведомления по электронной почте с достаточным предварительным уведомлением, чтобы возразить.

13. Права субъектов данных и удаление

• Право доступа и переносимости, `GET /v3/sessions/:session_id/decision/`.
• Право на удаление, `POST /v3/sessions/:session_id/delete/`. Удаляет сессию и все связанные артефакты во всех репликах.
• Хранение данных для каждого приложения настраивается в Бизнес-консоли в диапазоне от 30 дней до 10 лет; по умолчанию срок хранения неограничен, если клиент не настроит более короткий период. Хранение биометрических данных в любом случае регулируется и ограничивается применимыми законами и нормативными актами о конфиденциальности биометрических данных, включая статью 9 Общего регламента по защите данных ЕС (GDPR), Закон Иллинойса о конфиденциальности биометрической информации (BIPA), Закон Техаса о сборе или использовании биометрических идентификаторов (CUBI), Закон Вашингтона H.B. 1493 и любой другой применимый закон о конфиденциальности биометрических данных; если такой закон предписывает более короткий срок хранения или более раннее обязательство по уничтожению, это более короткое или строгое правило имеет преимущественную силу над любым сроком хранения по умолчанию или настроенным клиентом.
• См. Политику конфиденциальности и Уведомление о конфиденциальности верификации для полного процесса реализации прав субъектов данных.

14. Сообщение о проблеме безопасности

Если вы считаете, что обнаружили уязвимость безопасности в любом продукте или услуге Didit, отправьте электронное письмо на security@didit.me с описанием, шагами для воспроизведения и наблюдаемым воздействием. Didit подтверждает получение отчетов о безопасности в течение 2 рабочих дней и добросовестно сотрудничает с репортерами, которые следуют практике ответственного раскрытия информации.

15. Контакты

• Безопасность: security@didit.me
• Сотрудник по защите данных: dpo@didit.me
• Конфиденциальность: privacy@didit.me
• Юридические вопросы / контракты: legal@didit.me
• Запрос пакета доверия (под NDA): security@didit.me