Обеспечение соответствия мобильного приложения требованиям ISO 27001
ISO 27001 — международный стандарт управления информационной безопасностью. В отличие от GDPR или HIPAA, он не привязан к конкретному типу данных или юрисдикции. Это система управления (ISMS), которую нужно построить, задокументировать и пройти аудит у аккредитованного сертификационного органа.
Для мобильного приложения ISO 27001 означает: все процессы разработки, деплоя и эксплуатации встроены в ISMS организации. Технические контроли — только часть требований.
Что Annex A означает для разработки
ISO 27001:2022 содержит 93 контроля в Annex A, сгруппированных в 4 темы. Для мобильной разработки наиболее значимые:
A.8 Technological controls — большинство технических мер:
- A.8.2 Privileged access rights — кто имеет доступ к signing keys, production API keys, сертификатам
- A.8.7 Protection against malware — проверка сторонних SDK на уязвимости перед включением
- A.8.9 Configuration management — все конфигурации под контролем версий, нет захардкоженных секретов
- A.8.20 Networks security — TLS везде, network security config, certificate pinning
- A.8.24 Use of cryptography — AES-256 для at rest, TLS 1.3 для in transit, управление ключами
A.5 Organizational controls — процессы:
- A.5.8 Information security in project management — security by design в SDLC
- A.5.23 Information security for use of cloud services — vendor assessment для каждого облачного провайдера
- A.5.30 ICT readiness for business continuity — backup, DR план
Технические контроли в мобильном приложении
Управление секретами
Захардкоженные API ключи в коде — нарушение A.8.9 и частая находка при аудите. В мобильном приложении секреты никогда не должны попадать в репозиторий:
// Неправильно — нарушение A.8.9
val apiKey = "sk-prod-abc123xyz"
// Правильно — через BuildConfig из CI/CD секретов
val apiKey = BuildConfig.API_KEY
// Ещё лучше — ключ получается с сервера при аутентификации
val apiKey = tokenManager.getApiKey()
Для iOS — через xcconfig файлы, которые не коммитятся в репозиторий, и через Info.plist из CI/CD environment.
GitLeaks в pre-commit hook и в CI pipeline обнаруживает случайные коммиты с секретами.
Управление криптографическими ключами (A.8.24)
ISO 27001 требует задокументированной политики управления ключами: срок ротации, процедура ротации, хранение. Для мобильного приложения:
- Сертификаты TLS: ротация за 30 дней до истечения, certificate pinning обновляется через OTA конфиг (не хардкод)
- App signing keys: хранение в HSM или облачном key management (AWS KMS, Google Cloud KMS), не на локальном диске разработчика
- Encryption keys для local data: в Android Keystore / iOS Secure Enclave, без экспорта
Vulnerability Management (A.8.7, A.8.8)
Документированный процесс:
- SAST — статический анализ при каждом PR (MobSF в CI, Semgrep custom rules)
- Dependency scanning — Dependabot или OWASP Dependency-Check для обнаружения уязвимых библиотек
- Pentest — ежегодно или после крупных изменений. Отчёт хранится как свидетельство для аудитора
- Remediation SLA — критические уязвимости: 24 часа; высокие: 7 дней; средние: 30 дней
Для ISO 27001 аудитора нужны не просто инструменты, а documented process с proof of execution.
Secure SDLC (A.5.8)
ISO 27001 требует, чтобы безопасность была встроена в процесс разработки:
- Threat modeling при проектировании новых features — STRIDE или PASTA, документированный результат
- Security requirements в acceptance criteria каждого эпика
- Security-фокусированное code review для изменений, затрагивающих аутентификацию, шифрование, хранение данных
- Тестирование безопасности перед каждым major release
Документация, которая нужна для сертификации
Аудитор ISO 27001 смотрит на документы. Для мобильного приложения обязательны:
- Asset inventory — перечень информационных активов: исходный код, signing keys, production данные, документация
- Risk register — оценка рисков для каждого актива: угрозы, вероятность, impact, обработка
- Statement of Applicability (SoA) — какие контроли применяются, какие исключены и почему
- Incident response plan — процедура при security инциденте (утечка данных, компрометация signing key)
- Supplier security policy — требования к безопасности для сторонних SDK и облачных сервисов
Область сертификации
ISO 27001 сертифицирует организацию, а не приложение. Область (scope) ISMS определяется в документе: «разработка и поддержка мобильного приложения X, включая сопутствующую инфраструктуру». Аудитор проверяет всё в этой области.
Если нет ресурсов на полную сертификацию — можно пройти добровольную оценку соответствия (self-assessment по ISO 27001) и получить отчёт о gap analysis. Многие клиенты принимают это как промежуточный шаг.
Сроки
Gap analysis + roadmap: 1–2 недели. Внедрение технических контролей: 4–8 недель. Документирование ISMS + подготовка к аудиту: 2–4 месяца. Полный цикл до сертификации: 4–9 месяцев.