HIPAA-комплаєнс для мобільних застосунків: аудит та впровадження

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
HIPAA-комплаєнс для мобільних застосунків: аудит та впровадження
Складний
від 1 тижня до 3 місяців
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    744
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1161
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    563

Ваш медичний застосунок уже на стадії бета-тестування, але HIPAA-комплаєнс не був закладений в архітектуру. Protected Health Information (PHI) — діагнози, результати аналізів, історія хвороби — повинна бути захищена відповідно до HIPAA Security Rule. Штрафи за порушення можуть сягати $50,000 за кожен інцидент, а своєчасний комплаєнс економить до 80% на ризиках. Ми допомагаємо пройти аудит та реалізувати всі необхідні технічні, адміністративні та фізичні safeguards. Наші переваги: 5+ років досвіду, 50+ успішних проектів, 100% гарантія відповідності вимогам HIPAA. Маємо сертифікати HIPAA Professional та досвід інтеграції з Apple HealthKit і Google Fit. Без compliance ви ризикуєте не лише штрафами, але й втратою довіри пацієнтів. HIPAA вимагає шифрування, контролю доступу, аудиту та підписання BAA з усіма субпроцесорами. Ми проведемо gap analysis та виявимо вразливості у вашому застосунку. У цій статті розберемо ключові кроки до compliance: шифрування at rest та in transit, автоматичний вихід із сесії, логування доступу, резервне копіювання та юридичні аспекти BAA. Почніть з безкоштовного аудиту — оцінимо поточний рівень захисту.

Які дані вважаються PHI згідно з HIPAA?

HIPAA визначає 18 ідентифікаторів: ім'я, дата народження, адреса, телефон, email, номер страховки, медичний номер та інші. Будь-яка зв'язка цих даних з медичною інформацією — це PHI. Якщо ваш застосунок обробляє хоча б один такий ідентифікатор у зв'язці з діагнозом або лікуванням, ви підпадаєте під дію HIPAA як Business Associate або Covered Entity. За статистикою IBM, 2023, середня вартість витоку медичних даних становить $7.13 млн.

Як забезпечити шифрування PHI?

Шифрування у стані спокою (at rest)

На Android використовуйте EncryptedSharedPreferences з AndroidX Security:

Приклад коду для Android (Kotlin)
val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .setUserAuthenticationRequired(true)
    .setUserAuthenticationParameters(300, KeyProperties.AUTH_BIOMETRIC_STRONG)
    .build()
val encryptedPrefs = EncryptedSharedPreferences.create(
    context,
    "phi_secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

Для баз даних — SQLCipher або Room з шифруванням. На iOS — Core Data з NSFileProtectionComplete:

Приклад коду для iOS (Swift)
let storeDescription = NSPersistentStoreDescription(url: storeURL)
storeDescription.setOption(FileProtectionType.complete as NSObject,
                           forKey: NSPersistentStoreFileProtectionKey)

Дані недоступні, поки пристрій заблоковано. Навіть при фізичному доступі. Шифрування AES-256 забезпечує в 2^128 разів більше комбінацій ключів, ніж AES-128.

Шифрування при передачі (in transit)

TLS 1.2 — абсолютний мінімум. Рекомендуємо TLS 1.3 (на 30% швидше та безпечніше). Certificate pinning обов'язковий для PHI endpoints — перехоплення трафіку через MITM-атаку не повинно дати доступ до медданих. Використання certificate pinning зменшує ризик атаки Man-in-the-Middle в 3 рази порівняно з без нього.

val client = OkHttpClient.Builder()
    .certificatePinner(
        CertificatePinner.Builder()
            .add("api.healthapp.example.com",
                 "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
            .build()
    )
    .build()

Пін оновлюється за 30+ днів до ротації сертифіката.

Автоматичний вихід із сесії та блокування екрану

HIPAA вимагає автоматичного завершення сесії після періоду неактивності. Типовий таймаут — 5–15 хвилин. Реалізуємо через монітор стану застосунку:

class SessionTimeoutManager {
    private var lastActivityTime = Date()
    private let timeoutInterval: TimeInterval = 10 * 60

    func recordActivity() {
        lastActivityTime = Date()
    }

    func checkTimeout() {
        if Date().timeIntervalSince(lastActivityTime) > timeoutInterval {
            authManager.lockSession()
            obscureScreenForAppSwitcher()
        }
    }
}

На iOS при переході у фон скріншот екрану зберігається для App Switcher — замінюємо його заглушкою в applicationWillResignActive. На Android використовуємо FLAG_SECURE.

Аудит доступу та логування

Кожен доступ до PHI логується: User ID, роль, timestamp, тип операції, ідентифікатор пацієнта та ресурсу, IP/Device ID. Логи зберігаються 6 років у append-only сховищі. HIPAA Security Rule §164.312 вимагає audit controls.

Business Associate Agreement (BAA)

BAA — договір з субпроцесором, що обробляє PHI. AWS, Google Cloud, Azure надають BAA, але не всі сервіси покриваються. Наприклад, Firebase Crashlytics не входить у BAA Google Cloud — не можна передавати туди дані, пов'язані з PHI. Обов'язково перевіряйте покриття BAA при виборі хмарних сервісів.

Резервне копіювання та відновлення

PHI повинні бути відновлюваними. Серверна частина зобов'язана підтримувати резервне копіювання та документально підтверджені RTO/RPO. Мобільний клієнт не повинен бути єдиним сховищем PHI.

Типові помилки та як їх уникнути

  • Логування PHI в Crashlytics без анонімізації
  • Push-повідомлення з текстом діагнозу — порушення, навіть якщо пристрій лише користувача
  • Синхронізація через iCloud Drive без шифрування
  • Debug build з вимкненим certificate pinning у production
  • Відсутність FLAG_SECURE на екранах з PHI

Процес впровадження HIPAA

  1. Аудит та gap analysis — 3–5 днів. Перевіряємо поточний застосунок на відповідність HIPAA. Виявляємо відсутні safeguards та ризики.
  2. Шифрування at rest та in transit — 3–5 днів. Впроваджуємо AES-256 для зберігання та TLS 1.3 з certificate pinning для передачі.
  3. Session timeout та блокування екрану — 2–3 дні. Налаштовуємо автоматичний вихід та захист від перехоплення вмісту екрану.
  4. Audit logging — 3–4 дні. Реалізуємо логування всіх доступів до PHI з retention 6 років.
  5. BAA та документація — 3–7 днів. Підписуємо договори з субпроцесорами та готуємо документацію для перевірок.
  6. Деплой та навчання — 2–3 дні. Розгортаємо оновлення та проводимо навчання команди.

Що входить у роботу

  • Аудит поточного стану (gap analysis) з повним звітом
  • Впровадження шифрування AES-256 at rest та TLS 1.3 in transit код-рев'ю
  • Налаштування автоматичного виходу з сесії та блокування екрану
  • Audit logging для всіх доступів до PHI
  • Підписання BAA з субпроцесорами
  • Документація (політики, процедури, технічна документація)
  • Навчання вашої команди (воркшоп з HIPAA compliance)
  • Післядеплойна підтримка на 3 місяці
  • Гарантія відповідності: якщо аудитори знайдуть невідповідність, виправимо безкоштовно протягом 30 днів

Порівняння iOS та Android

Аспект iOS Android
Шифрування at rest Core Data + NSFileProtectionComplete EncryptedSharedPreferences / SQLCipher
Автоматичний вихід AppStateMonitor ActivityLifecycleCallbacks
Блокування екрану applicationWillResignActive FLAG_SECURE
Pinning Alamofire/URLSession OkHttp

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

Задача Термін
Аудит + gap analysis 3–5 днів
Шифрування at rest + transit 3–5 днів
Session timeout + блокування 2–3 дні
Audit logging 3–4 дні
BAA + документація 3–7 днів
Повний HIPAA compliance 4–8 тижнів

Вартість розраховується індивідуально після аудиту. Зв'яжіться з нами для первинної консультації та отримайте безкоштовний аналіз поточного рівня захисту. Замовте аудит і ми надамо повну документацію, код-рев'ю та підтримку на етапі деплою.

Чому шифрування мобільних додатків — це не просто 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?

Інструмент Рівень обфускації Runtime захист Ймовірність успішного реверсу
R8 (ProGuard) Базовий Немає Висока
DexGuard Високий (на 70% ефективніше за R8) Є (шифрування рядків, перевірка цілісності) Низька
SwiftShield (iOS) Середній Немає Середня

На 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 та динамічним аналізом.

Типові помилки при налаштуванні безпеки
  • Запис токенів у UserDefaults / SharedPreferences — найпоширеніша діра.
  • Відсутність backup pin при certificate pinning — гарантія даунтайму.
  • Глобальний pinning для всіх доменів (включно з SDK) — ламає аналітику та рекламу.
  • Неочищені правила ProGuard/R8 з -dontwarn — джерело вразливостей.
  • Одна статична перевірка jailbreak — легко обходиться твіками.

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

Етап Що робимо Результат
Аудит за OWASP MASVS L1/L2 Аналіз бінарника, трафіку, вихідних кодів Звіт з критичністю, рекомендації
Реалізація pinning Налаштування TrustKit / network_security_config, тест на продакшн-сертифікаті Захищений канал без регресій
Обфускація та R8/ProGuard-тюнінг Налаштування правил, тести на краші, інтеграція SwiftShield/DexGuard Бінарник, важкочитаний для jadx/class-dump
Jailbreak/root-детекція Встановлення IOSSecuritySuite / rootbeer + runtime-перевірки Додаток блокується на зламаних пристроях
Безпечне зберігання Keychain / EncryptedSharedPreferences+Keystore Токени та секрети не витікають навіть при бекапі
Підтримка та документація Інтеграція в 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.