Шифрование данных в мобильном приложении строится на трёх уровнях: защита при хранении на устройстве (Keychain, Keystore, SQLCipher), защита при передаче по сети (TLS 1.3 + certificate pinning) и грамотное управление ключами. Провал на любом из трёх уровней обнуляет остальные два — поэтому проектировать их нужно вместе, ещё до написания кода.

Почему шифрование — это три отдельные задачи

Когда заказчик говорит «нам нужно шифрование», за этой фразой обычно скрываются три разные инженерные проблемы. Данные живут в трёх состояниях: лежат на устройстве пользователя, летят по сети к серверу и обрабатываются в памяти. Атаки на каждое состояние разные: украденный телефон, перехват трафика в публичном Wi-Fi, реверс-инжиниринг APK с зашитым в код ключом.

За 18 лет работы и 300+ проектов мы в Applications.kz видели одну и ту же закономерность: команды старательно настраивают HTTPS, но хранят токен авторизации в обычном файле настроек и держат ключ шифрования прямо в исходниках. Такая защита снимается за вечер. Поэтому при разработке мобильных приложений мы закладываем модель угроз на этапе архитектуры, а не «прикручиваем безопасность» перед релизом.

Для Казахстана это не абстракция: закон «О персональных данных и их защите» обязывает оператора принимать меры по защите данных, а с 2024 года базы персональных данных казахстанцев должны храниться на территории РК. Если приложение работает с ИИН, платежами или медицинскими записями — шифрование становится юридическим требованием, а не опцией.

Шифрование при хранении: что и где держать на устройстве

Главный принцип — не хранить лишнего. Лучший способ защитить данные на устройстве — не записывать их туда вовсе. Всё, что можно держать на сервере и запрашивать по требованию, должно жить на сервере. Для остального есть аппаратные хранилища.

Keychain (iOS) и Keystore (Android)

Токены, пароли, PIN-коды и криптографические ключи хранятся только в системных защищённых хранилищах. На iOS это Keychain с атрибутом доступности kSecAttrAccessibleWhenUnlockedThisDeviceOnly — данные недоступны при заблокированном экране и не переносятся в резервные копии. На Android — Keystore с генерацией ключей внутри аппаратного модуля (StrongBox на устройствах, где он есть): ключ физически не покидает чип, приложение лишь просит систему выполнить операцию.

Базы данных и файлы

Локальную базу шифруем целиком: SQLCipher для SQLite, встроенное шифрование Realm, для настроек на Android — EncryptedSharedPreferences из Jetpack Security. Отдельная зона риска — кэши: скриншоты экранов в карусели многозадачности, логи, временные файлы загрузок. В банковских и медицинских приложениях мы закрываем экран заглушкой при сворачивании и отключаем запись чувствительных полей в логи на уровне линтера.

  • Секреты (токены, ключи) — Keychain / Keystore, никогда файлы и UserDefaults;
  • Структурированные данные — зашифрованная БД (SQLCipher, Realm encryption);
  • Файлы — шифрование AES-256-GCM с ключом из аппаратного хранилища;
  • Кэш и логи — фильтрация чувствительных полей до записи.

Шифрование при передаче: TLS — это только минимум

HTTPS сегодня включён по умолчанию: App Transport Security на iOS и network security config на Android блокируют незашифрованные соединения. Но «у нас HTTPS» не равно «трафик защищён». Стандартный TLS доверяет любому сертификату из системного хранилища — а значит, атакующий с установленным на устройство корневым сертификатом (или скомпрометированный удостоверяющий центр) читает трафик как открытую книгу.

Certificate pinning

Пиннинг привязывает приложение к конкретному публичному ключу сервера: даже валидный, но чужой сертификат будет отвергнут. Мы пиннируем не сам сертификат, а хэш публичного ключа (SPKI) — так плановая замена сертификата не ломает приложение. Обязательно закладываем резервный пин и механизм обновления пинов без релиза, иначе истёкший сертификат превратится в массовый отказ у всех пользователей одновременно.

Для особо чувствительных операций — платежи, передача биометрии — добавляем шифрование полезной нагрузки поверх TLS: тело запроса шифруется отдельным ключом ещё до отправки. Тогда даже вскрытый TLS-канал не отдаёт атакующему ничего читаемого.

Управление ключами: самое слабое звено

Алгоритмы ломают редко — ключи крадут постоянно. AES-256 математически надёжен, но бесполезен, если ключ лежит строкой в коде: декомпиляция APK занимает минуты, и «зашифрованная» база открывается найденным ключом. Это самая частая находка наших аудитов.

Правильная схема выглядит так:

  1. Генерация на устройстве. Ключ создаётся внутри Keystore/Secure Enclave при первом запуске и никогда не существует в виде строки в коде или конфиге.
  2. Иерархия ключей. Мастер-ключ в аппаратном модуле шифрует рабочие ключи данных (envelope encryption). Компрометация одного рабочего ключа не раскрывает весь архив.
  3. Деривация, а не хранение. Ключи из пользовательского PIN выводим через PBKDF2 или Argon2 с достаточным числом итераций — сам PIN нигде не сохраняется.
  4. Ротация. Серверные ключи живут в KMS (AWS KMS, HashiCorp Vault) и меняются по расписанию; процедура отзыва прописана заранее, а не придумывается во время инцидента.
  5. Биометрия как замок. Face ID / отпечаток не заменяет ключ, а разблокирует доступ к нему: ключ помечается как требующий аутентификации, и система не выдаст его без подтверждения владельца.

Типичные ошибки, которые мы находим в чужом коде

К нам регулярно приходят проекты «на доработку», и проблемы повторяются от приложения к приложению:

  • ключ шифрования или API-секрет зашит в константу — извлекается утилитой strings без декомпиляции;
  • токен авторизации в SharedPreferences/UserDefaults открытым текстом;
  • самописная криптография вместо проверенных библиотек — собственный «XOR с солью» вскрывается студентом;
  • ECB-режим AES вместо GCM — одинаковые блоки данных дают одинаковый шифротекст, структура просвечивает;
  • отключённая проверка сертификатов «временно, для отладки», уехавшая в продакшен;
  • чувствительные данные в стек-трейсах краш-репортов — связка краш-аналитики с фильтрацией полей решает это за день.

Большинство таких дыр отлавливается до релиза обычной дисциплиной: статический анализ (MobSF, Semgrep) в CI и обязательное код-ревью каждого изменения, затрагивающего авторизацию, хранение и сеть. Безопасность — это в первую очередь процесс, а уже потом набор библиотек.

Сколько стоит внедрение шифрования в Казахстане

Цифры ниже — ориентиры для рынка КЗ на 2026 год; точная смета зависит от стека, объёма легаси и требований регулятора. Если приложение только проектируется, отдельной строки «шифрование» в смете обычно нет — защита входит в архитектуру с первого дня, и это всегда дешевле, чем переделывать готовое.

Работа Срок Стоимость, ₸
Аудит безопасности приложения (хранение, сеть, ключи) 1–2 недели 400 000 – 900 000
Перенос секретов в Keychain/Keystore + шифрование локальной БД 1–3 недели 500 000 – 1 200 000
Certificate pinning с резервными пинами и обновлением без релиза 1–2 недели 300 000 – 700 000
Сквозная схема управления ключами (KMS, ротация, envelope) 2–4 недели 800 000 – 2 000 000
Комплексное внедрение «под ключ» для существующего приложения 4–8 недель 1 500 000 – 4 000 000

Мы работаем с проектами в Казахстане, ОАЭ и Таиланде; команда базируется в Алматы. Если вам нужна разработка мобильного приложения в Алматы с защитой данных, заложенной в архитектуру, — пришлите описание задачи на +7 (707) 928-13-15, и мы подготовим смету за 24 часа.

Как проверить своё приложение прямо сейчас

Быстрый самоконтроль, не требующий специалиста по безопасности:

  • поищите в репозитории строки key =, secret, password — секретов в коде быть не должно;
  • откройте файлы SharedPreferences / UserDefaults на тестовом устройстве — токены не должны читаться глазами;
  • пропустите трафик приложения через прокси (Charles, mitmproxy) с собственным сертификатом — запросы к вашему API должны падать, если пиннинг работает;
  • проверьте, что скриншот в карусели многозадачности не показывает баланс, ИИН или номер карты;
  • прогоните сборку через MobSF — бесплатный сканер находит до половины типовых проблем автоматически.

Если хотя бы один пункт провален — приложение хранит или передаёт данные небезопасно, и это вопрос времени, когда уязвимость найдёт кто-то ещё.

Частые вопросы

Достаточно ли HTTPS для защиты данных при передаче?

Нет. HTTPS защищает канал от пассивного перехвата, но не от атаки «человек посередине» с подменным сертификатом — например, через корневой сертификат, установленный на устройство. Минимальный рабочий набор: TLS 1.2+, certificate pinning по хэшу публичного ключа и резервные пины, чтобы плановая замена сертификата не сломала приложение у всех пользователей.

Шифрует ли iOS и Android данные приложения автоматически?

Частично. Обе системы шифруют накопитель целиком, но эта защита работает только пока устройство выключено или заблокировано. После разблокировки файлы доступны любому процессу с правами приложения, а на устройствах с root/jailbreak — и сторонним инструментам. Поэтому чувствительные данные дополнительно шифруются на уровне приложения с ключами из Keychain/Keystore.

Какой алгоритм шифрования выбрать для мобильного приложения?

Для данных — AES-256 в режиме GCM (он даёт и шифрование, и контроль целостности), для обмена ключами — ECDH на кривой P-256 или X25519, для паролей — Argon2id или PBKDF2 с высоким числом итераций. Главное правило: использовать системные API и проверенные библиотеки (CryptoKit, Tink, libsodium), а не писать криптографию самостоятельно.

Что требует казахстанский закон о персональных данных?

Закон РК «О персональных данных и их защите» обязывает оператора принимать правовые, организационные и технические меры защиты, а базы персональных данных граждан РК — хранить на территории Казахстана. Конкретные алгоритмы закон не диктует, но при утечке именно отсутствие шифрования будет трактоваться как непринятие достаточных мер со всеми вытекающими санкциями.

Сколько времени занимает добавление шифрования в готовое приложение?

Зависит от объёма долга. Перенос токенов в защищённое хранилище и включение пиннинга — одна-три недели вместе с тестированием. Полный цикл «аудит → шифрование хранения → пиннинг → схема управления ключами» для среднего приложения занимает один-два месяца. Точный срок назовём после аудита кода — смету готовим за 24 часа.