Обеспечение соответствия мобильного приложения требованиям 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-ключи в коде — частая находка при аудите. Секреты никогда не должны попадать в репозиторий:

// Неправильно — нарушает 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

Сертификация даёт официальное подтверждение, которое self-assessment не обеспечивает. Экономия на услугах аудитора при правильной подготовке составляет до 40%.

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

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

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

Сроки и как начать

Ориентировочные сроки:

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

Стоимость рассчитывается индивидуально — зависит от текущего уровня безопасности и сложности приложения. Получите консультацию по сертификации ISO 27001 для вашего мобильного приложения. Свяжитесь с нами для оценки проекта — мы поможем пройти путь до сертификата с минимальными рисками.

В процессе мобильной разработки по ISO 27001 мы внедряем все необходимые контроли, чтобы ваше приложение соответствовало мировым стандартам безопасности и получило доверие клиентов и партнёров.

Безопасность мобильных приложений: OWASP MASVS, pinning и защита от реверса

Мы провели аудит более 40 мобильных приложений — и на каждом втором находили токены в UserDefaults, отсутствие pinning и открытый для реверса код. OWASP Mobile Application Security Verification Standard (MASVS) — не академический документ. Это чек-лист пентестера. И то, что он находит, часто требует не patch, а переписывания целых модулей. Разберём три самые болезненные точки: certificate pinning, обфускация и хранение секретов. И покажем, как их закрыть без даунтаймов на продакшне.

Почему certificate pinning ломает продакшн?

Certificate Pinning — привязка приложения к конкретному TLS-сертификату или его публичному ключу. Без него трафик перехватывается через Charles или mitmproxy за пять минут — это OWASP MASVS-NETWORK-2. Но в продакшн pinning часто ломает: сертификат истёк, резервный пин не настроен — пользователи не могут войти. Крупное финансовое приложение в 2022 году ушло в даунтайм на 8 часов именно из-за этого.

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

На 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 сломается. Конфигурация должна быть поддоменно-специфичной.

Как защитить данные в 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% за первый месяц.

Обфускация и защита кода

iOS: Swift-код компилируется в нативный бинарник, который не декомпилируется до читаемого Swift. Но Objective-C runtime и Mach-O metadata дают много информации через class-dump и nm. Имена классов, методов, строки в бинарнике — всё видно. Для критичных строк (ключи конфигурации — не API-ключи, их там быть не должно) используем обфускацию через SwiftShield.

Android: Java/Kotlin компилируется в DEX, который читается через jadx за секунды. R8 (включён по умолчанию в release сборках) минифицирует и обфусцирует. Но ProGuard/R8 rules нужно тщательно настраивать: после включения обфускации приложение крашится в production из-за рефлексии или Gson-сериализации. Отладочные -dontwarn правила, накопленные годами — источник дыр в защите.

Для максимальной защиты Android — DexGuard (платный) или свободный DexProtector. Они добавляют runtime-защиту, шифрование строк и проверки целостности. Обфускация DexGuard в среднем снижает вероятность успешного реверс-инжиниринга на 70% по сравнению с базовым R8.

Обнаружение jailbreak и root

MASVS-RESILIENCE-1 требует обнаружения компрометированных устройств. Стандартные проверки: наличие /Applications/Cydia.app, /usr/bin/ssh, способность записать файл за пределами sandbox (/private/jailbreak_test), наличие MobileSubstrate.

Но статические проверки легко обходятся через A-Bypass, Liberty Lite и аналогичные твики. Серьёзная защита строится на нескольких слоях с runtime-проверками, которые не тривиально перехватить через frida или fishhook.

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

Что входит в работу по безопасности мобильного приложения

Как мы реализуем защиту: кейс

Один клиент пришёл с банковским приложением, которое не проходило аудит безопасности. Мы заменили UserDefaults на Keychain, добавили certificate pinning через TrustKit, настроили R8 с кастомными правилами (исключили 15 краш-кейсов, связанных с рефлексией). Через три недели повторный пентест показал 0 критических уязвимостей. С момента внедрения — ни одного инцидента за два года.

Сроки и стоимость

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

Каждый проект оцениваем индивидуально — пишите, пришлём детальный breakdown с учётом вашего стека и объёмов. Работаем под ключ: от анализа до деплоя в сторах.

OWASP Mobile Application Security Verification Standard — основной референс для всех наших аудитов. Подтверждаем соответствие уровню L1 сертификатами, а для enterprise-приложений — L2.

Оценим ваш проект за один рабочий день после получения APK/IPA. Свяжитесь — расскажем, какие дыры закроем в первую очередь.