Безопасность приложения и персональные данные: 152-ФЗ
Где должны храниться данные приложения, какие разрешения действительно нужны и что требуют метки конфиденциальности по 152-ФЗ и GDPR.
Команда rabbitclipПубликация: 5 мин чтения
Коротко
Безопасность приложения начинается со сбора как можно меньшего количества данных: то, что никогда не собрано, никогда не может утечь. Приложение сначала решает, какие данные действительно нужны, затем определяет, где и как эти данные хранятся, какие разрешения запрашивает и как все это указывает в метке конфиденциальности магазина.
С середины 2020-х и Apple, и Google требуют от каждого приложения метку конфиденциальности: App Privacy Details у Apple, Data safety у Google Play; если эта метка не совпадает с тем, что приложение реально собирает, есть риск отклонения при проверке или удаления позже. Российский федеральный закон 152-ФЗ «О персональных данных» и, в случае работы с пользователями из Евросоюза, GDPR устанавливают каждый в своем правовом поле, какие данные можно обрабатывать и для какой цели.
В этой статье разбирается, где должны храниться данные, какие разрешения действительно нужны, что требуют метки конфиденциальности магазинов, что требует 152-ФЗ, шифрование и безопасность сессии, и в завершение - пошаговый чек-лист безопасности.
Где должны храниться данные: на устройстве или на сервере
Хранение на устройстве означает, что такая информация, как имя пользователя или токен сессии, находится в собственном защищенном хранилище телефона, Keychain у Apple, Keystore у Android; эти данные остаются недоступными, даже если человек теряет телефон, если только не взломана сама блокировка экрана. Токен сессии, записанный в незашифрованном виде в обычный текстовый файл или область общих настроек, такой защиты не получает.
Для серверных данных реальный вопрос в том, где они физически размещены; если данные жильцов приложения управления домом хранятся на сервере в России, правила 152-ФЗ о трансграничной передаче данных не вступают в действие, но перенос этих же данных на сервер за рубежом требует отдельного правового основания для такой передачи.
Приложение должно заранее решить, какие данные могут оставаться на устройстве, а какие обязательно должны перемещаться на сервер; данные, перенесенные на сервер без необходимости, добавляют и риск передачи, и ответственность за хранение.
Разрешения: какое действительно нужно
Разрешение оправдано только тогда, когда оно служит функции, реально используемой в данный момент; доступ к геолокации нужен для отслеживания курьера в приложении доставки, тогда как то же разрешение не служит никакой функции в приложении для чтения электронных книг. Запрос ненужного разрешения подрывает доверие человека с самого начала и может привести к запросу обоснования при проверке в магазине.
Доступ к геолокации нужно рассматривать по-разному в зависимости от того, «только при использовании приложения» это или «всегда»; вне приложения для отслеживания доставки в реальном времени большинству приложений опция «всегда» не нужна, ее запрос и настораживает человека, и привлекает дополнительную проверку.
Чувствительные разрешения, такие как камера, микрофон или контакты, следует запрашивать только в момент, когда затрагивается соответствующая функция; запрос всех разрешений подряд при первом запуске приводит к тому, что человек отклоняет большинство из них.
Что требуют метки конфиденциальности магазинов
App Privacy Details от Apple и Data safety от Google Play - это декларационные формы, которые делают видимой прямо на странице магазина, какую категорию данных собирает приложение и для чего ее использует. Форма основана на собственной декларации разработчика, но если эта декларация не совпадает с реальным поведением приложения, и Apple, и Google расценивают это как нарушение правил.
Когда в приложение добавляется сторонняя библиотека аналитики или рекламы, то, что собирает эта библиотека, тоже должно быть включено в декларацию; разработчик, который указывает только то, что собирает его собственный код, и пропускает библиотеку, оставляет декларацию неполной.
Эти метки нужно пересматривать при каждом обновлении версии; если новая функция собирает новую категорию данных, метка должна отражать это изменение.
Что требует 152-ФЗ
152-ФЗ требует, чтобы обработка персональных данных обосновывалась явным согласием или иным основанием, предусмотренным законом, для четко указанной цели; если приложение собирает данные пользователя, цель их использования должна быть ясно прописана в политике конфиденциальности. Передача этих данных на сервер, размещенный за рубежом, например облачный сервис с базой в другой стране, требует отдельного правового основания и должна соответствовать условиям, установленным для трансграничной передачи, а надзор за соблюдением закона осуществляет Роскомнадзор.
Если приложение обслуживает и российских пользователей, и пользователей из Евросоюза, ему нужна политика конфиденциальности, удовлетворяющая одновременно 152-ФЗ и GDPR, действующему через собственные надзорные органы каждой страны ЕС; один общий текст может оставить оба требования невыполненными.
Право человека потребовать удаления своих данных существует в обеих системах; приложению нужен реальный способ выполнить такой запрос, удаление аккаунта, форма запроса данных, а полагаться только на письмо перестает быть жизнеспособным по мере роста базы пользователей.
Шифрование и безопасность сессии
Каждое соединение между приложением и сервером должно быть зашифровано, HTTPS поверх TLS; пароль или платежные данные, отправленные по незашифрованному соединению, может прочитать другое устройство в той же сети. Это больше не вопрос предпочтения, а минимальное требование как по правилу App Transport Security от Apple, так и по базовой практике безопасности.
Истечение срока токена сессии через заданный период и поддержка биометрической блокировки, отпечатка пальца, распознавания лица, не дает конфиденциальным данным долго оставаться доступными на потерянном или украденном телефоне. В B2B-приложении для снабжения сессия, которая никогда не истекает, ставит под угрозу данные компании в тот момент, когда сотрудник теряет телефон.
Пошагово: чек-лист безопасности
Ниже минимальный чек-лист, который приложение должно пройти перед запуском.
- По каждому собираемому полю данных спросить, действительно ли оно нужно, и убрать лишнее
- Хранить чувствительные данные в защищенном хранилище устройства (Keychain/Keystore), а не в обычном текстовом файле
- Запрашивать каждое разрешение только в момент, когда затрагивается соответствующая функция, а не все сразу при запуске
- Сверить метку конфиденциальности магазина, включая сторонние библиотеки, с реальным потоком данных
- Проверить политику конфиденциальности отдельно на соответствие 152-ФЗ и локальным требованиям целевого рынка, например GDPR
- Построить способ внутри приложения для обработки запросов на удаление, не полагаясь только на письмо
Безопасность приложения строится на сборе минимума данных, правильном хранении оставшегося и точном указании этого в метке магазина и политике конфиденциальности. На ознакомительном звонке с rabbitclip проверяется существующий поток данных, и вместе выявляются пробелы относительно 152-ФЗ и местных требований целевого рынка.
Частые вопросы
Что происходит, если метка конфиденциальности магазина заполнена неверно?
Если декларация не совпадает с реальным поведением, Apple и Google расценивают это как нарушение правил; приложение может быть отклонено или удалено позже.
Можно ли всегда запрашивать разрешение на геолокацию как «разрешить всегда»?
Только когда функция действительно нуждается в непрерывном отслеживании, например отслеживание курьера в реальном времени; большинству приложений достаточно варианта «только при использовании».
Может ли одна политика конфиденциальности удовлетворять и 152-ФЗ, и GDPR?
Общий текст может оставить оба требования невыполненными; требования каждой системы нужно проверять отдельно.
Почему важно, где размещены данные?
Страна, где размещены данные, определяет, вступают ли в действие правила о трансграничной передаче; передача за рубеж требует отдельного правового основания.
