Обеспечение соответствия мобильного приложения требованиям SOC 2

Обеспечение соответствия мобильного приложения требованиям SOC 2

SOC 2 — это не закон и не регулятор. Это аудиторский стандарт (AICPA), который крупные корпоративные клиенты требуют от SaaS-вендоров и мобильных приложений, обрабатывающих их данные. Если B2B-приложение хочет работать с Enterprise-клиентами в США и Западной Европе — SOC 2 Type II отчёт открывает двери, которые иначе закрыты.

Что SOC 2 означает для мобильного приложения

SOC 2 строится на Trust Service Criteria (TSC). Для большинства мобильных приложений релевантны три:

• Security — обязателен всегда
• Availability — если приложение критично для бизнес-процессов клиента
• Confidentiality — если обрабатываются конфиденциальные данные клиентов

Каждый критерий — набор контролей (CC). Аудитор проверяет не намерения, а доказательства: логи, конфигурации, процедуры, результаты тестирования. SOC 2 Type II — это аудит за период (обычно 12 месяцев), а не снимок состояния.

Технические контроли на стороне мобильного клиента

Большинство SOC 2 контролей реализуется на серверной стороне. Мобильный клиент отвечает за несколько специфических областей:

CC6.1 — Logical and Physical Access Controls

Многофакторная аутентификация. Для корпоративных пользователей SOC 2 фактически требует MFA. В мобильном приложении это TOTP (Google Authenticator / Authy совместимый), push-based аутентификация (через Firebase или собственный push) или biometric + PIN.

// Проверка наличия биометрии как второго фактора
val biometricManager = BiometricManager.from(context)
when (biometricManager.canAuthenticate(BIOMETRIC_STRONG)) {
    BIOMETRIC_SUCCESS -> enableBiometricMFA()
    BIOMETRIC_ERROR_NO_HARDWARE -> requireTOTP()
    BIOMETRIC_ERROR_NONE_ENROLLED -> promptUserToEnrollBiometric()
}

Автоматический выход и блокировка сессии. Session timeout после периода неактивности — типичный контроль CC6.1. Для B2B приложений: 15–30 минут неактивности → блокировка, требующая повторной аутентификации (не полного logout).

CC6.7 — Transmission of Data

Certificate pinning для всех API endpoints. Не только производственных — staging среда с тестовыми данными клиентов тоже должна быть защищена. Отдельный пин для staging, документированный в runbook ротации.

Логирование всех API запросов с ошибками 4xx/5xx — не на устройстве, на сервере. Аудитор попросит примеры логов за период.

CC7.2 — Monitoring of System Components

Tampering detection. SOC 2 аудитор спросит: как вы обнаруживаете, что клиентское приложение модифицировано? Ответ должен включать техническое решение:

// SafetyNet Attestation API (устаревает, замена — Play Integrity API)
val integrityManager = IntegrityManagerFactory.create(context)
val integrityTokenResponse = integrityManager.requestIntegrityToken(
    IntegrityTokenRequest.builder()
        .setNonce(serverGeneratedNonce)
        .build()
)
// Токен верифицируется на сервере через Google API

На iOS — DeviceCheck + AppAttest для верификации подлинности приложения на серверной стороне.

CC9.2 — Vendor and Business Partner Management

Каждый SDK в приложении — вендор. SOC 2 аудитор спросит: есть ли vendor assessment для Firebase, Amplitude, Braze? Какие данные они получают? Какой их SOC 2 статус?

Ответ: список всех SDK с указанием данных, которые они получают, ссылки на их SOC 2 отчёты (у Firebase, AWS, Amplitude они есть публично или по NDA). Это vendor inventory — документ, который нужно поддерживать актуальным.

Свидетельства (Evidence) для аудитора

SOC 2 аудит — это сбор доказательств. Для мобильного приложения типичные артефакты:

Continuous Compliance

SOC 2 Type II — это 12 месяцев доказательств. Нельзя внедрить контроли за неделю до аудита. Нужен pipeline:

• SAST в CI/CD (Semgrep, Snyk) с блокировкой при критических находках
• Автоматическое обновление dependency с Dependabot / Renovate
• Periodic access review — кто имеет доступ к production данным
• Incident response procedure с задокументированными примерами

Сроки

Подготовка к SOC 2 Type I (снимок состояния): 4–8 недель технических работ + документации. SOC 2 Type II требует 6–12 месяцев работы контролей перед аудитом. Стоимость рассчитывается после gap analysis.