Information Security Policy

Настоящая Политика информационной безопасности описывает сертификаты 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, а также ориентированные на клиента Услуги, описанные в Условиях ведения бизнеса. Она поддерживается Заявлением о применимости, которое является основой системы управления ISO/IEC 27001:2022 Didit.

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

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

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

• В состоянии покоя: AES-256 для каждой производственной базы данных, объектного хранилища и тома резервного копирования.
• При передаче: TLS 1.3 для каждого внешнего вызова API, веб-хука и сессии Business Console. Старые версии 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) запускаются автоматически при каждом pull request.
• Сканирование контейнеров и инфраструктуры при каждой сборке и по расписанию для развернутых образов.
• Предпроизводственное тестирование безопасности для высокорисковых изменений (аутентификация, управление ключами, биометрические конвейеры, платежные потоки).
• Внутренние тесты на проникновение непрерывно; внешние тесты на проникновение не реже одного раза в год независимыми специалистами. Существенные обнаружения отслеживаются до закрытия по графику, ограниченному SLA.
• Канал Bug-bounty / ответственного раскрытия, сообщайте о проблемах безопасности на security@didit.me.

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

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

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

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

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

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

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

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

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

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

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

• Право доступа и переносимости, `GET /v3/sessions/:session_id/decision/`.
• Право на удаление, `POST /v3/sessions/:session_id/delete/`. Удаляет сессию и все связанные артефакты во всех репликах.
• Хранение для каждого приложения настраивается в Business Console в диапазоне от 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