Забезпечення 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 при зберіганні, TLS 1.3 при передачі, управління ключами
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 для кожного cloud провайдера
- 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 конфіг (не hardcod)
- App signing keys: зберігання в HSM або cloud KMS (AWS KMS, Google Cloud KMS), не на локальному диску розробника
- Encryption keys для local data: в Android Keystore / iOS Secure Enclave, без експорту
Управління уязвимостями (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 аудитора потрібні не просто інструменти, а задокументований процес з доказом виконання.
Secure SDLC (A.5.8)
ISO 27001 вимагає, щоб безпека була вбудована в процес розробки:
- Threat modeling при проектуванні нових features — STRIDE або PASTA, задокументований результат
- Security requirements у acceptance criteria кожного епіка
- Security-фокусоване code review для змін, що стосуються аутентифікації, шифрування, зберігання даних
- Тестування безпеки перед кожним major release
Документація, потрібна для сертифікації
Аудитор дивиться на документи. Для мобільного додатку обов'язкові:
- 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 місяців.