Что такое песочница (sandbox) приложений в Android и iOS

Коротко: песочница (sandbox) — это изолированная область, в которой работает каждое приложение на смартфоне: у него свой набор прав и своё хранилище данных, а доступ к чужим файлам, камере или контактам без разрешения пользователя запрещён на уровне операционной системы, а не только интерфейса. Android и iOS реализуют эту модель по-разному — через UID с ядром Linux или через контейнер с правами по подписи, — но цель у обеих одна: не дать одному приложению прочитать данные другого.
Что такое песочница приложений простыми словами
Песочница — это изолированная среда выполнения, в которую операционная система помещает каждое установленное приложение. Внутри своей «песочницы» программа видит только собственные файлы, собственную память и те системные возможности, которые ей явно разрешили. У соседнего приложения — своя точно такая же изолированная ячейка, и по умолчанию одна ячейка не может заглянуть в другую.
Самое заметное для пользователя следствие этой модели — всплывающие запросы вида «Разрешить доступ к камере?» или «Разрешить доступ к контактам?». Это не отдельная настройка «про разрешения», а видимая часть работы песочницы: приложение физически не может получить данные или функции за пределами своей ячейки, пока система (а значит, и пользователь) не разрешит это явно. Изоляция происходит на уровне ядра и системных механизмов, а не на уровне интерфейса — обойти её, просто «кликнув мимо» диалога, нельзя.
Как это работает в Android: UID, ядро Linux и SELinux
Android построен поверх ядра Linux, и первый слой изоляции здесь — классический Unix-механизм прав доступа. При установке каждому приложению назначается собственный уникальный идентификатор пользователя — UID — и оно запускается как отдельный процесс под этим UID, в собственной виртуальной машине. Файлы приложения по умолчанию принадлежат только его UID, и ядро штатными средствами Linux (права user/group) не даёт прочитать их процессу с другим UID — ровно так же, как на обычном многопользовательском Linux-сервере один пользователь не видит файлы другого.
Поверх базовой Unix-модели Android добавляет SELinux — обязательный контроль доступа (mandatory access control), который действует независимо от того, что «разрешено» классическими правами файлов, и его нельзя ослабить из самого приложения. Эта защита усиливалась постепенно, от версии к версии: Android 5.0 обеспечил принудительное разделение процессов системы и приложений через SELinux, Android 6.0 добавил границы между профилями разных пользователей устройства, Android 8.0 ввёл фильтр системных вызовов seccomp-bpf, ограничивающий саму возможность обратиться к ядру, Android 9 сделал индивидуальную SELinux-песочницу обязательной для всех непривилегированных приложений и запретил доступ к чужим данным «для всех по умолчанию», а Android 10 убрал прямой доступ к общим путям файловой системы вроде /sdcard/DCIM, заменив его фильтрованным представлением.
Отсюда и ещё одно правило: обмениваться файлами приложения должны не через открытый доступ к хранилищу, а через системные посредники — Content Provider и MediaStore. Это официально задокументированный механизм (Android Open Source Project, Application Sandbox): приложение-источник явно решает, какими данными поделиться, а не оставляет общий каталог открытым для всех.
Как это работает в iOS: контейнер приложения вместо прав Unix
iOS решает ту же задачу иначе. Вместо модели «пользователь и права файла», как в Android, каждое приложение получает собственный контейнер — отдельное место в файловой системе со строго определённой структурой. Внутри контейнера — каталог Documents для данных, которые создаёт сам пользователь (он же попадает в резервную копию iCloud), Bundle с неизменяемым кодом и ресурсами приложения, Library для кэша и настроек и tmp для временных файлов, которые система может удалить в любой момент. По умолчанию приложение видит только свой контейнер — выйти за его пределы и прочитать файлы соседнего приложения оно не может в принципе, какие бы права ни запрашивало.
Если приложению всё же нужно поработать с чем-то вне своего контейнера, iOS предлагает для этого отдельные явные механизмы, а не «доступ ко всему хранилищу»: UIDocumentPickerViewController — системный выбор файла, который пользователь указывает сам; Security-Scoped Bookmarks — постоянная «закладка», дающая приложению право вернуться к однажды выбранному файлу; и App Groups — общее пространство для обмена данными между несколькими приложениями одного разработчика. Какие именно права и возможности доступны конкретному приложению, определяется entitlements — списком разрешений, который подписывается вместе с самим приложением при публикации (официальное руководство Apple по безопасности рантайм-процесса iOS, iPadOS и visionOS).
Android и iOS — два разных способа решить одну задачу
Если сопоставить подходы напрямую, разница видна по уровню, на котором строится изоляция.
| Параметр | Android | iOS |
|---|---|---|
| Единица изоляции | UID + отдельный процесс | Контейнер приложения |
| Кто разграничивает доступ | Ядро Linux + SELinux | Файловая система + entitlements |
| Источник прав | Разрешения, запрошенные в манифесте и у пользователя | Entitlements, подписанные при сборке приложения |
| Применимость | Любой процесс в системе, включая системные | Прежде всего прикладные приложения |
Android изолирует на уровне операционной системы и ядра — это универсальный механизм, который одинаково действует и на сторонние приложения, и на системные процессы. iOS строит изоляцию вокруг самого приложения как единицы — контейнера с чётко описанной структурой и правами, выданными при подписании. При этом конечная цель у обеих моделей совпадает: приложение A не должно прочитать данные приложения B без явного разрешения — просто к этой цели каждая платформа идёт своим архитектурным путём.
Что песочница реально защищает в вашем телефоне
Для пользователя эта инженерная модель превращается в конкретную, повседневную защиту.
- Банковские данные. Даже если на телефоне окажется заражённое трояном приложение, оно не сможет прочитать файлы и ключи авторизации банковского приложения — они физически недоступны за пределами его собственной ячейки.
- Переписка в мессенджерах. История сообщений хранится в изолированном хранилище конкретного мессенджера; другое приложение, даже установленное рядом, не имеет к нему прямого доступа.
- Камера, микрофон, геолокация, контакты. Каждый такой запрос доступа — это видимое следствие песочницы: приложение обращается за разрешением выйти за пределы своей изолированной области, и система каждый раз спрашивает пользователя, прежде чем это допустить.
Та же логика стоит и за биометрией: когда приложение вызывает сканер отпечатка пальца или Face ID, оно не получает сами биометрические данные — оно лишь спрашивает у системы подтверждение, а сама биометрическая информация остаётся в защищённом хранилище вне доступа приложения. Подробнее о том, как это устроено, — в материале про биометрию смартфона: сканер отпечатка и Face ID. Похожий принцип действует и в бесконтактных платежах: когда приложение вроде Google Pay или Apple Pay обращается к защищённому элементу через NFC-модуль, оно делает это через системный API, а не напрямую — доступ к платёжным данным так же опосредован разрешениями, как и доступ к любому другому ресурсу за пределами песочницы приложения.
Эта же модель — одна из причин, почему грамотная реализация мобильного приложения требует профильной экспертизы: правильно запросить нужные разрешения, не просить лишнего и корректно работать в рамках песочницы системы — отдельная инженерная задача и для Android, и для iOS. Командам, которым нужно сделать такое приложение под обе платформы сразу, обычно проще обратиться к студии с опытом кроссплатформенной разработки — например, к команде YuSMP Group, которая разрабатывает мобильные приложения сразу под Android и iOS.
Что песочница НЕ решает — ограничения модели
У модели песочницы, как и у любой защиты, есть честные границы — она не всесильна.
- Не защищает от фишинга и социальной инженерии. Если пользователь сам разрешил подозрительному приложению доступ к контактам или файлам, песочница этот выбор не отменит — она ограничивает только несанкционированный доступ, а не санкционированный по ошибке.
- Не изолирует данные от самого приложения. Если доступ выдан явно, приложение, которому доверились, может использовать его так, как захочет, — в рамках выданного разрешения.
- Обходится при root и джейлбрейке. Получение повышенных прав на устройстве нарушает целостность доверенной среды, на которой держится вся модель, — приложения с root-доступом могут обойти границы, которые в обычных условиях непреодолимы.
- Не заменяет шифрование и аппаратную защиту ключей. Песочница изолирует процессы и файлы приложений на уровне операционной системы, но это другой уровень защиты, чем отдельный аппаратный чип для хранения криптографических ключей — подробнее о том, как это устроено и чем он дополняет песочницу, в материале что такое Secure Enclave и TPM в смартфоне.
Куда развивается модель песочниц
Android продолжает поэтапно ужесточать модель изоляции: от обязательного разделения системы и приложений через SELinux в версии 5.0 до индивидуальной SELinux-песочницы для каждого непривилегированного приложения в версии 9 и фильтрованного доступа к общим путям файловой системы в версии 10 — каждая новая версия сокращает поверхность, через которую приложения в принципе могли бы получить лишнее. iOS идёт похожим путём, постепенно сужая набор операций, которые приложение может выполнить без явного системного посредника.
Поверх технической изоляции обе платформы добавляют ещё один слой — курируемое распространение приложений. Проверка приложений перед публикацией в App Store и постоянное сканирование установленных приложений сервисом Google Play Protect не отменяют песочницу, а работают вместе с ней: песочница ограничивает, что приложение может сделать технически, а проверка площадки снижает шанс, что вредоносное приложение вообще окажется на устройстве пользователя.
Частые вопросы
Может ли одно приложение прочитать данные другого приложения без разрешения?
Нет: при штатной работе ОС это заблокировано на уровне ядра (Android) или контейнера (iOS), а не только интерфейса — приложения физически не видят чужие файлы и данные.
Защищает ли песочница от вирусов?
Песочница снижает ущерб от вредоносного приложения — оно не достанет данные других программ, — но не защищает от того, что пользователь сам разрешил запрошенному приложению, и не заменяет антивирус или проверку источника установки.
Почему root и джейлбрейк считаются риском для безопасности?
Root и джейлбрейк разрушают границы песочницы: приложения с повышенными правами получают доступ к данным и системным функциям, которых у них не должно быть, и модель изоляции перестаёт гарантированно работать.
В чём принципиальная разница между песочницей и TPM/Secure Enclave?
Песочница изолирует процессы и данные приложений на уровне операционной системы, а TPM/Secure Enclave — отдельный аппаратный чип для хранения криптографических ключей. Это разные, дополняющие друг друга уровни защиты.


