Перейти к содержанию

TODO — открытые вопросы BOT 18/2568

Дата: 2026-04-23 Связанные документы: - 01-response.md — официальный ответ - 02-internal-notes.md — внутренний разбор с решениями

Список вопросов, которые нужно закрыть для полного соответствия BOT Notification 18/2568. Формат: [ ] — открыт, [~] — в работе, [x] — закрыт. Разделено на блоки: Организационные / Compliance / Legal, Продуктовые, Инженерные.

  • A-1 Назначить Security / Brand Protection officer (кто отвечает за fake apps monitoring, TB-CERT feed, incident response).
  • A-2 Подписать партнёрское соглашение с Google Play Protect — takedown flow для поддельных приложений. Требует DUNS, юр. лица.
  • A-3 Подписать партнёрское соглашение с Apple App Store Brand Protection.
  • A-4 Оформить подписку на TB-CERT feed (список high-risk устройств). Требует юр. шаг — уточнить у BOT, обязательно ли для e-Money operator быть членом TB-CERT.
  • A-5 Согласовать с compliance/legal конкретные пороги step-up authentication:
  • Per-transaction threshold (предложение: 50 000 THB).
  • Daily cumulative threshold (предложение: 200 000 THB).
  • Нужно ли использовать KYC tier как модификатор?
  • A-6 Уточнить у BOT, какие точно значения daily/monthly limits требуются для e-Money Tier 1 и Tier 2 — свериться с текущими значениями в payment_limits.
  • A-7 Согласовать policy по root/jailbreak: hard-block или soft-warn? BOT формально требует hard-block.
  • A-8 Согласовать policy по одновременно запущенным accessibility / screen-sharing приложениям: hard-block на high-value / soft-warn на остальных?
  • A-9 Выбрать исполнителя face liveness: Gemini multi-frame vs AWS Rekognition Face Liveness ($0.025/check) vs FaceTec (commercial). Решение зависит от точности и стоимости.
  • A-10 Определить retention policy для attestation token логов и user_device записей после revoke (предложение: 1 год).
  • A-11 Подготовить evidence pack для будущего внешнего аудита: скриншоты TLS-конфига, pin-list, политики, результаты пентеста.
  • A-12 Запланировать pre-launch пентест мобильного приложения (third-party).

B. Продуктовые

  • B-1 Решить UX для «1 user per device»: что делает пользователь, желающий переключить аккаунт? (logout всех других устройств / confirm screen / запрет переключения без revoke).
  • B-2 Решить UX для force-update: full-screen модал с deep link в Store? Локализация сообщений (TH, EN, RU).
  • B-3 Решить UX для step-up: экран с selfie + liveness внутри платёжного flow — прерывать или открывать модально?
  • B-4 Решить UX для screen-capture / accessibility предупреждения — блокировать полностью или показывать dismissable warning?
  • B-5 Решить UX для анти-скриншот: FLAG_SECURE на всех sensitive экранах vs только платежи + KYC. Влияет на support (клиент не может прислать скриншот своей проблемы).
  • B-6 Определить behaviour «баланс скрыт при возврате из background» — тап + биометрия раскрывает? Опция в настройках?
  • B-7 Согласовать тексты email / in-app баннера «We never ask to click links to verify identity» (TH, EN, RU).
  • B-8 Определить, какое количество активных устройств на пользователя разрешено (предложение: 3, но уточнить).

C. Инженерные (разработка)

C.1 Документация и политики

  • C-1.1 Добавить раздел «Communication Policy» в docs/11-security-policy.md (no-links policy).
  • C-1.2 Добавить раздел «Mobile Device Security» §10 в docs/11-security-policy.md (объединённая спека по attestation / device binding / root-detect / screen protection).
  • C-1.3 Добавить таблицу justifications для permissions в docs/01-mobile-app.md.
  • C-1.4 Написать runbook docs/runbooks/fake-app-response.md.
  • C-1.5 Написать runbook docs/runbooks/jwt-key-rotation.md (emergency rotation).
  • C-1.6 Обновить §7.2 docs/11-security-policy.md — liveness из P2 в P0.

C.2 Backend (Serverpod / PM)

  • C-2.1 Модель UserDevice (spy.yaml + миграция).
  • C-2.2 Модель DeviceBlocklistEntry (spy.yaml + миграция).
  • C-2.3 Модель AppVersion (spy.yaml + миграция).
  • C-2.4 AuthEndpoint.registerDevice / listMyDevices / revokeDevice.
  • C-2.5 Добавить claim device_id в JWT; validate в middleware.
  • C-2.6 SecurityEndpoint.attestDevice({token, nonce}) + интеграция с Play Integrity API / Apple App Attest.
  • C-2.7 AppVersionEndpoint.check({platform, version}) + Gateway middleware 426 Upgrade Required.
  • C-2.8 Расширить Intent state machine: новый state AWAITING_STEP_UP.
  • C-2.9 PaymentEndpoint.confirmStepUp(intentId, selfieUrl) + кэш успешного step-up (Redis, 15 мин).
  • C-2.10 Добавить payment_limits.step_up_threshold (column add via spy.yaml).
  • C-2.11 Реализовать face-match для step-up в KYCService (переиспользование Gemini client).
  • C-2.12 Cron-job для импорта TB-CERT feed в device_blocklist.
  • C-2.13 Admin Panel: страница /settings/app-versions.
  • C-2.14 Admin Panel: страница /security/devices (список устройств, revoke).
  • C-2.15 Admin Panel: страница /security/device-blocklist.
  • C-2.16 Алерт: >1% операций близко к дневному лимиту.
  • C-2.17 Добавить события в Unified Log: security.attestation.failed, security.device.rooted, security.fake_app.detected, security.screen_capture.detected, security.concurrent_app.detected, security.device_blocklist.hit, security.app_version.outdated.
  • C-2.18 Ротация JWT signing key: JWKS с kid (если ещё не сделано).
  • C-2.19 Добавить backup TLS certificate pin (primary + backup) и задокументировать процедуру ротации.

C.3 Flutter (onewallet_base_flutter)

  • C-3.1 Интеграция device_info_plus + стабильный deviceId (Keychain / EncryptedSharedPreferences).
  • C-3.2 Вызов registerDevice после login / register.
  • C-3.3 Экран настроек «Мои устройства» (список + revoke).
  • C-3.4 Интеграция Play Integrity SDK (Android).
  • C-3.5 Интеграция App Attest (iOS).
  • C-3.6 Вызов attestDevice при каждом re-auth (cold start, after logout).
  • C-3.7 FLAG_SECURE на sensitive экранах (Android) — через flutter_windowmanager.
  • C-3.8 Blur overlay в applicationWillResignActive (iOS, native channel).
  • C-3.9 Observer UIScreen.main.isCaptured (iOS) — блок sensitive UI при captured.
  • C-3.10 Jailbreak/root detection — freerasp или flutter_jailbreak_detection.
  • C-3.11 Обфускация release-сборки: --obfuscate --split-debug-info=.
  • C-3.12 R8/ProGuard в android/app/build.gradle.
  • C-3.13 Проверить iOS Release settings: STRIP, POSTPROCESSING, no debug logs.
  • C-3.14 Audit permissions: AndroidManifest.xml + Info.plist — удалить лишние.
  • C-3.15 Проверка версии приложения на старте + каждые 6 часов → force-update UI.
  • C-3.16 Step-up UI: selfie + liveness flow внутри платежа.
  • C-3.17 Accessibility services check (Android, native channel) + предупреждающий оверлей.
  • C-3.18 Welcome/Settings: баннер «We never ask to click links».
  • C-3.19 Баланс скрыт при возврате из background (тап + биометрия).
  • C-3.20 Линтер: avoid_print в release, удалить все debugPrint.
  • C-3.21 dart-define для всех секретов — убедиться, что в коде нет хардкода.

C.4 Email / коммуникации

  • C-4.1 Обновить все email-шаблоны в projects/onewallet_base/onewallet_base_server/lib/src/mail/ — добавить disclaimer о no-links-policy.
  • C-4.2 Локализация disclaimer (TH, EN, RU).

C.5 Тестирование и аудит

  • C-5.1 Unit + integration тесты для registerDevice / attestDevice.
  • C-5.2 E2E тест step-up flow на high-value transaction.
  • C-5.3 Golden test для UI со включённым FLAG_SECURE (смоки).
  • C-5.4 Smoke тест: залогиниться под user_A на device, залогиниться под user_B на том же device → user_A должен получить force-logout.
  • C-5.5 Pentest mobile app (third-party) — перед go-live.
  • C-5.6 Pentest backend attestation endpoints (third-party).

План по фазам

Фаза 0 — 1 неделя (быстрые победы, без инженерии)

  • A-5, A-6, A-7, A-8, A-9 — решения от compliance/legal
  • C-1.1, C-1.3, C-1.4, C-1.5, C-1.6 — документация
  • C-3.14, C-3.20, C-3.21 — audit permissions, удалить debug prints
  • C-4.1, C-4.2 — email disclaimer
  • C-3.11, C-3.12, C-3.13 — включить обфускацию (ничего больше не трогая)

Фаза 1 — 2–3 недели (mobile hardening basic)

  • C-3.1…C-3.3 — device binding client
  • C-2.1, C-2.4, C-2.5 — device binding backend
  • C-3.7, C-3.8, C-3.9 — screen protection
  • C-3.10 — root/jailbreak detect
  • C-2.3, C-2.7, C-3.15 — force update
  • C-3.18, C-3.19 — UI disclaimers и балансы

Фаза 2 — 2–3 недели (attestation + step-up)

  • C-2.6, C-3.4, C-3.5, C-3.6 — Play Integrity / App Attest
  • C-2.8, C-2.9, C-2.10, C-2.11, C-3.16 — step-up flow
  • C-2.17, C-2.18, C-2.19 — logging и ротация ключей

Фаза 3 — 1–2 недели (device blocklist + concurrent apps)

  • A-4 (параллельно, юр.) — подписка TB-CERT
  • C-2.2, C-2.12, C-2.15 — device blocklist
  • C-3.17, C-2.14 — concurrent apps
  • C-2.13 — admin UI для app_versions

Фаза 4 — параллельно с Фазой 3 (Brand Protection)

  • A-1, A-2, A-3 — юр. оформление
  • C-1.2 — финальная документация

Фаза 5 — 1 неделя (тесты + pentest)

  • C-5.1…C-5.6 — все тесты и pentest
  • A-11, A-12 — evidence pack и финальный аудит

Общая оценка: 8–10 недель с двумя разработчиками (mobile + backend) и привлечением compliance/legal.