Забезпечення відповідності мобільного додатка вимогам ISO 27001

Ми часто зустрічаємо проєкти, де мобільний застосунок уже працює, але клієнт хоче отримати сертифікат ISO 27001 для виходу на міжнародні ринки або виконання тендерних вимог. Стандарт вимагає не лише технічних заходів, а й побудови системи управління інформаційною безпекою (ISMS). Без цієї системи аудит не пройти. Нещодавно ми допомогли фінтех-стартапу з ЄС пройти сертифікацію за 6 місяців: основні проблеми були з управлінням секретами та документуванням ризиків. Повністю переписали CI/CD, впровадили GitLeaks і MobSF, підготували SoA з нуля. Клієнт пройшов аудит з першої спроби.

ISO 27001 — міжнародний стандарт, який, на відміну від GDPR або HIPAA, не прив'язаний до конкретного типу даних чи юрисдикції. Це система управління, яку потрібно задокументувати та пройти аудит акредитованого органу. Наш досвід показує: більшість проблем виникає саме на етапі документування процесів, а не на технічних контролях. Наприклад, на підготовку документації йде до 60% загального часу проєкту. Для точної оцінки вашого проєкту зв'яжіться з нами.

Для мобільного застосунку ISO 27001 означає, що всі процеси розробки, деплою та експлуатації вбудовані в ISMS організації. Технічні контролі — лише частина вимог. Ми допомагаємо компаніям пройти цей шлях від gap analysis до сертифікації. Ми маємо 5+ років досвіду на ринку та реалізували 20+ проєктів з безпеки мобільних застосунків.

Чому ISO 27001 важливий для мобільного додатка?

Сертифікат підтверджує, що процеси розробки захищені на рівні світових стандартів. Це необхідно для роботи з фінансовими установами, медичними даними або державними замовленнями. Без ISO 27001 багато клієнтів просто не розглядають продукт. Сертифікований застосунок отримує в 3 рази більше довіри клієнтів порівняно з несертифікованим.

Як забезпечити відповідність мобільного застосунку вимогам ISO 27001

Ми розбиваємо роботу на два блоки: технічні контролі та документація ISMS. Ось головні технічні заходи.

Управління секретами (контроль A.8.9)

Захардкоджені API-ключі в коді — часта знахідка при аудиті. Управління секретами та вразливостями (vulnerability management) є критичними для мобільного застосунку. Секрети ніколи не повинні потрапляти в репозиторій:

// Неправильно — порушує A.8.9
val apiKey = "sk-prod-abc123xyz"

// Правильно — через BuildConfig із CI/CD секретів
val apiKey = BuildConfig.API_KEY

// Ще краще — ключ отримується з сервера при аутентифікації
val apiKey = tokenManager.getApiKey()

Для iOS використовуємо xcconfig-файли, які не комітяться. Додаємо GitLeaks в pre-commit hook та CI pipeline. Згідно з ISO 27001, контроль A.8.9, секрети повинні зберігатися окремо від вихідного коду та передаватися через безпечні канали.

Управління криптографічними ключами (контроль A.8.24)

Стандарт вимагає задокументованої політики: термін ротації, процедура, зберігання. Для мобільного застосунку:

• Сертифікати TLS: ротація за 30 днів до закінчення, certificate pinning оновлюється через OTA-конфіг.
• Ключі підпису: зберігання в HSM або хмарному key management (AWS KMS, Google Cloud KMS).
• Ключі шифрування локальних даних: в Android Keystore або iOS Secure Enclave.

Vulnerability Management (контролі A.8.7, A.8.8)

Документований процес із доказами:

1. SAST — статичний аналіз при кожному PR (MobSF у CI, Semgrep custom rules).
2. Dependency scanning — Dependabot або OWASP Dependency-Check.
3. Pentest — щорічно або після великих змін. Звіт зберігається для аудитора.
4. SLA на виправлення: критичні — доба, високі — тиждень, середні — місяць.

Secure SDLC (контроль A.5.8)

Моделювання загроз (STRIDE) при проєктуванні нових фіч, вимоги безпеки в acceptance criteria, code review для змін, що зачіпають аутентифікацію або шифрування. Все це фіксується в документації.

Яка документація потрібна для сертифікації

Аудитор дивиться не на код, а на документи. Обов'язковий набір. Нижче — таблиця з описом ключових документів.

Всі документи версіонуються та підписуються. Самостійна підготовка займає в 2 рази більше часу і часто містить помилки — з нами ви проходите цей швидше.

Порівняння: ISO 27001 vs self-assessment

ISO 27001 сертифікація в 2 рази ефективніша за self-assessment для залучення клієнтів. Сертифікація дає офіційне підтвердження, яке self-assessment не забезпечує. Економія на послугах аудитора при правильній підготовці становить до 40%.

Що входить у нашу роботу

Ми супроводжуємо проєкт від gap analysis до отримання сертифіката. В рамках співпраці ви отримуєте:

• Повну документацію ISMS (шаблони та заповнені документи під ваш проєкт).
• Налаштування CI/CD для безпечного управління секретами.
• Впровадження SAST та dependency scanning.
• Підготовку до аудиту та супровід на всіх етапах.
• Навчання команди процесам ISMS.
• Пост-сертифікаційну підтримку (щорічні аудити).

Як підготуватися до аудиту ISO 27001?

Перед аудитом ми проводимо попередню перевірку готовності, усуваємо невідповідності та навчаємо команду відповідати на запитання аудитора. Ми гарантуємо якісне документування та супровід до отримання сертифіката. Наш багаторічний досвід підтверджується успішними проєктами.

Терміни та як почати

Орієнтовні терміни:

• Gap analysis + дорожня карта: 1–2 тижні.
• Впровадження технічних контролів: 4–8 тижнів.
• Документування ISMS: 2–4 місяці.
• Повний цикл до сертифікації: 4–9 місяців.

Вартість розраховується індивідуально — залежить від поточного рівня безпеки та складності застосунку. Gap analysis коштує від 500 €, а повна підготовка до сертифікації — від 8 000 €. Отримайте консультацію з сертифікації ISO 27001 для вашого мобільного застосунку. Зв'яжіться з нами для оцінки проєкту — ми допоможемо пройти шлях до сертифіката з мінімальними ризиками.

У процесі мобільної розробки за ISO 27001 ми впроваджуємо всі необхідні контролі, щоб ваш застосунок відповідав світовим стандартам безпеки та отримав довіру клієнтів і партнерів.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.