Android безопасность – Безопасность Android 8. Объясняем все новшества в механизмах защиты Oreo — «Хакер»

Безопасность данных в разработке мобильных приложений / Habr

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

Все нижесказанное — исключительно мой опыт, безусловно, данные могут быть неточными, поэтому буду благодарен за любые поправки и дополнения к статье. Я не нашел исчерпывающих статей в сети на подобную тематику, которые бы собирали всю нужную (хотя бы базовую) информацию в одном месте, поэтому решил обобщить свой опыт в этой области на текущий момент времени.

Защита мобильного приложения

Основные виды атак на мобильное приложение:

• Декомпиляция файла приложения (.ipa-файлы для Apple iOS и .apk-файлы для Google Android) и разбор локально сохраненных данных. Защита этого, наиболее важного в настоящее время, уровня целиком лежит на плечах мобильного разработчика.
• Перехват данных, передаваемых по сети (MITM-атаки). Большинство мобильных приложений являются клиент-серверными, следовательно, постоянно передают и принимают большие объемы информации. И хотя современная мобильная и веб-разработка активно завершают переход на HTTPS-протокол общения, тем не менее, не стоит полагаться на единственный рубеж защиты в виде защищенного канала связи.
• Рутование устройства и атака на приложение и применяемые в нем алгоритмы через внешние отладочные инструменты.

Перечень основных уязвимостей приложений

Рассмотрим уязвимости общего характера, без привязки к конкретной платформе. Здесь и далее используется аббревиатура КВД — критически важные данные пользователей. К КВД относятся любые данные, которые не должны быть доступны третьей стороне, это касается как персональных данных пользователя (дата рождения, адрес проживания, личная переписка), так и его приватных данных (пароли, данные кредитных карт, номера банковских счетов, номера заказов и так далее).

Перечень основных уязвимостей следующий:

• Использование незащищенных локальных хранилищ.

  
  
  • Опасность: Очень высокая.
  • Комментарий: Встречается повсеместно, выражается в хранении КВД в незащищенных или слабо защищенных локальных хранилищах, специфических для конкретной платформы. Вскрытие третьей стороной — элементарное, и, как правило, не требуется наличие специальных навыков у атакующего.
  • Защита: Хранить КВД можно только в защищенных хранилищах платформы.
  
  

• Хранение КВД в коде.

  
  
  • Опасность: Высокая.
  • Комментарий: Уязвимость касается хранения КВД внутри кода (в статических константных строках, в ресурсах приложения и т.п.). Яркие примеры: хранение соли для пароля (password salt) в константе или макросе, которая применяется по всему коду для шифрования паролей; хранение приватного ключа для асимметричных алгоритмов; хранение паролей и логинов для серверных узлов или баз данных. Легко вскрывается третьей стороной при наличии базовых навыков декомпиляции.
  • Защита: Не хранить никакие КВД в коде или ресурсах приложения.
  
  

• Применение алгоритмов с хранением приватного ключа.

  
  
  • Опасность: Высокая.
  • Комментарий: Уязвимость актуальна в случае, если приватная информация алгоритма (приватный ключ) вынужденно сохраняется в коде или ресурсах мобильного приложения (чаще всего так и бывает). Легко вскрывается методом декомпиляции.
  • Защита: В мобильной разработке желательно применять только современные симметричные алгоритмы с генерируемым случайным одноразовым ключом, обладающие высокой стойкостью с взлому методом грубой силы, либо выводить асимметричный приватный ключ за пределы приложения, либо персонализировать этот ключ (как пример — приватным ключом может выступать пользовательский код входа, сохраненный в зашифрованном виде в защищенном хранилище операционной системы).
  
  

• Использование асимметричного алгоритма с приватным ключом, известным серверу.

  
  
  • Опасность: Зависит от степени защищенности сервера.
  • Комментарий: Уязвимость носит двойной характер. Хранение приватного ключа допускает возможность расшифровки пользовательских данных на стороне сервера. Во-первых, это некорректно с точки зрения безопасности (если сервер будет взломан — атакующий также получит доступ к приватным данным пользователей), а во-вторых, это нарушает приватность персональных данных. Пользователь всегда должен быть уверен, что его персональная информация не известна никому, кроме него самого (только если он явно не дал разрешение на ее публикацию). Часто приложения позиционируют себя как защищенные, но на деле таковыми не являются, так как содержат внутри себя средства для расшифровки персональной информации.
  • Защита: Без явной необходимости и явного разрешения пользователя (чаще всего через лицензионное соглашение) ни приложение, ни сервер не должны иметь никакой возможности расшифровать приватные данные пользователя. Простейший пример — пароль пользователя должен уходить на сервер уже в виде хеша, и проверяться должен хеш, а не исходный пароль (серверу абсолютно незачем знать пользовательский пароль; если же пользователь его забыл — для такой ситуации существует давно отлаженный механизм восстановления пароля, в том числе с двухфакторной авторизацией клиента для повышенной безопасности процедуры восстановления).
  
  

• Использование самописных алгоритмов шифрования и защиты.

  
  
  • Опасность: Средняя.
  • Комментарий: Это прямое нарушение принципа Керкгоффса. Выражается в попытке разработчика изобрести «свой личный, не известный никому, а поэтому супер-защищенный алгоритм шифрования». Любое отклонение от существующих, многократно проверенных и изученных, математически доказанных алгоритмов шифрования в 99% случаев оборачивается быстрым взломом подобной «защиты». Требует наличия средне-высоких навыков у атакующего.
  • Защита: Следует подбирать подходящий алгоритм только из отлаженных и актуальных общеизвестных криптографических алгоритмов.
  
  

• Передача КВД во внешнюю среду в открытом виде.

  
  
  • Опасность: Средняя.
  • Комментарий: Выражается в передаче КВД без применения шифрования по любому доступному каналу связи с внешней средой, будь то передача данных стороннему приложению или передача в сеть. Может быть вскрыто опосредованно путем вскрытия не приложения, а его хранилища, или целевого приложения. Взлом требователен к наличию навыков у атакующего, при условии, что хранилище является защищенным.
  • Защита: Любые КВД перед выходом за пределы приложения должны быть зашифрованы. Локальные хранилища платформы не являются областью приложения, они тоже должны получать на вход только зашифрованные данные.
  
  

• Игнорирование факта наличия рутованных или зараженных устройств.

  
  
  • Опасность: Средняя.
  • Комментарий: Рутованные устройства — это девайсы, где выполнена модификация для получения прав суперпользователя на любые операции, изначально запрещенные производителем операционной системы. Выполняется пользователем на своем устройстве самостоятельно, и не обязательно добровольно (клиент может быть не в курсе, что устройство взломано). Установка приложения на рутованный девайс нивелирует все штатные средства защиты операционной системы.
  • Защита: Если это технически возможно для платформы — то желательно запрещать работу приложения, если удалось понять, что запуск производится на рутованном устройстве, или хотя бы предупреждать об этом пользователя (спасибо за дополнение DjPhoeniX).
  
  

• Хранение КВД в защищенных хранилищах, но в открытом виде.

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

• Перевод части функционала во встроенные веб-движки.

  
  
  • Опасность: Средняя.
  • Комментарий: Чаще всего выглядит как передача КВД во встроенный браузер, где загружается внешняя веб-страница, выполняющая свою часть функционала. Уровень защиты в этом случае резко снижается, особенно для рутованных устройств.
  • Защита: Не использовать встроенный браузер и встроенный веб-движок в операциях с КВД. На крайний случай — шифровать КВД перед передачей.
  
  

• Реверсивная инженерия алгоритмов, представляющих интеллектуальную ценность.

  
  
  • Опасность: Низкая, зависит от ценности алгоритма.
  • Комментарий: Если при разработке приложения внутри компании используются некие собственные алгоритмы, которые могут представлять высокую ценность для потенциальных конкурентов или взломщиков, то эти алгоритмы должны быть защищены от постороннего доступа.
  • Защита: Автоматическая или ручная обфускация кода.
  
  

Специфика разработки мобильных приложений

Есть несколько общих для всех мобильных платформ моментов, которые следует соблюдать при разработке.

Защита пользовательским кодом

• Если приложение защищено пользовательским паролем (PIN-кодом, сканом отпечатка пальца, графическим паролем и т.д.), то при уходе приложения в фон («сворачивании») оно должно немедленно отображать окно ввода этого защитного кода, перекрывая собой весь экран приложения. Это исключает возможность для злоумышленника получить приватную информацию в случае кражи устройства, пока приложение все еще запущено и находится в спящем режиме.
• Любой пользовательский код должен иметь ограниченное количество попыток ввода (например, 5 раз), затем, в случае неудачи, приложение должно автоматически разлогиниваться (или и вовсе блокироваться, зависит от конкретного приложения).
• В настоящее время при использовании цифровых кодов строго рекомендуется использовать ограничение на длину кода в минимум 6 цифр (больше можно, меньше — нельзя).

Функционирование клиент-серверного приложения

• Для клиент-серверных приложений очень полезно применять сессионный механизм с ограниченным временем жизни сессии. Это позволит избежать «простаивания» приложения в незащищенном режиме, если пользователь просто забыл закрыть его и оставил устройство в свободном доступе. Следует учитывать, что срок действия сессии и ее идентификатор относятся к КВД, со всеми вытекающими отсюда последствиями. Одним из удачных примеров реализации подобного механизма является получение абсолютного значения времени с сервера после прохождения процедуры авторизации пользователя (дата и время должны показывать, когда именно сессия станет неактивной). Дату и время окончания действия сессии не следует генерировать на устройстве, это снижает безопасность и гибкость приложения.
• Клиент-серверное приложение не должно осуществлять изменение КВД в локальном режиме. Любое действие, требующее изменения КВД, должно проходить синхронизацию с сервером. Исключение из этого правила составляет только пользовательский код входа, задаваемый лично пользователем и сохраненный в защищенном локальном хранилище.

Работа с датами

• При оперировании важными для работы приложения датами, вроде времени уничтожения сессии, не следует опираться на относительное время. То есть, передаваемые с сервера данные не должны содержать дату в виде «плюс N секунд/часов/дней от текущего момента». В силу наличия потенциально высоких задержек в передаче данных по сети от мобильного приложения к серверу и обратно, подобный способ синхронизации будет обладать слишком большой погрешностью. Кроме того, атакующий (или просто недобросовестный пользователь) может попросту сменить локальный пояс на устройстве, нарушив таким образом логику работы ограничительных механизмов приложения. Всегда нужно передавать только абсолютное значение времени.
• Абсолютные значения следует передавать с применением универсальных способов обмена подобной информацией, без привязки к часовому поясу конкретного пользовательского устройства. Чаще всего, оптимальным вариантом является поведение приложения, при котором данные отображаются пользователю в его локальном часовом поясе, но их хранение и передача осуществляется в формате, не привязанном к тайм-зоне. Подходящими форматами для дат и времени являются либо универсальный UNIX timestamp, сохраненный в переменной 64-битного целого знакового типа (UNIX timestamp — это количество секунд, прошедшее с 1 января 1970 года), либо, на крайний случай, строка в полном формате ISO-8601 с нулевой тайм-зоной. Предпочтителен именно UNIX timestamp, он позволяет избежать потенциальных ошибок и проблем с конвертацией строк в дату и обратно на разных мобильных платформах.

Дополнительные рекомендации

• Приложение не должно отображать приватную пользовательскую информацию большими, яркими, хорошо читаемыми шрифтами, без явной на то необходимости и без отдельного запроса пользователя, чтобы исключить возможность чтения этих данных издали с экрана устройства.
• Не стоит слепо доверять библиотекам с открытым исходным кодом, которые предлагают некую защиту приватным данным пользователей. Исключение составляют библиотеки, проверенные временем и используемые в крупных проектах корпораций (например, встроенное шифрование в открытом движке базы данных Realm). Штатных механизмов защиты операционной системы и общедоступных проверенных криптографических алгоритмов в подавляющем большинстве случаев будет более, чем достаточно.
• Абсолютно недопустимо использовать криптографические библиотеки с закрытым исходным кодом (даже если они платные). В таких решениях вы никак не сможете проверить, насколько эффективна данная библиотека, а также насколько «честная» у нее защита (нет ли там механизма backdoor, или не отсылаются ли «защищенные» данные какой-то третьей стороне).
• В релизных сборках приложений должно быть отключено логгирование данных в системную консоль и незащищенные файлы. Специфические логи для разработчиков могут присутствовать, но желательно в зашифрованном виде, во избежание доступа третьих лиц к закрытой служебной информации, которая может присутствовать в логах.

Специфическая информация по платформе iOS

Рассмотрим доступные для разработчика хранилища данных при разработке под iOS:

• NSUserDefaults.

  
  
  • Штатная защищенность: Отсутствует.
  • Комментарий: Используется только для хранения безопасных для функционирования приложения данных, не связанных с приватной информацией. Чаще всего туда записывают только клиентские настройки интерфейса. Для других данных это хранилище не подходит, так как представляет собой обычный файл и вскрывается за несколько секунд.
  
  

• Бинарные файлы (NSKeyedArchiver).

  
  
  • Штатная защищенность: Средняя, если пользоваться атрибутом NSFileProtectionComplete по ключу NSFileProtectionKey, иначе — отсутствует (спасибо за дополнение agee).
  • Комментарий: Сами по себе являются физическими файлами и могут быть элементарно доступны третьей стороне. Уровень защиты зависит исключительно от примененных к данным алгоритмов шифрования. Это не самое удобное место для хранения данных, поэтому без особой необходимости (чаще всего это возможность передавать эти данные, к примеру, по электронной почте) лучше подобный способ не применять. Если файл создан со значением атрибута NSFileProtectionComplete для ключа NSFileProtectionKey, то операционная система удерживает этот файл в зашифрованном состоянии, пока устройство заблокировано или находится в состоянии загрузки, но при несоблюдении этих условий данные будут доступны на чтение и запись, как в обычном файле, так что это лишь временная мера с узкой областью применения.
  
  

• Базы данных.

  
  
  • Штатная защищенность: Зависит от движка и разработчика.
  • Комментарий: Современные движки БД поддерживают внутреннее шифрование данных. Разработчику понадобится найти баланс между шифрованием и производительностью, включить шифрование базы для критических данных, а также дополнительно применять шифрование для КВД перед записью в базу.
  
  

• Связка ключей (Keychain).

  
  
  • Штатная защищенность: Максимальная (не распространяется на устройства с джейлбрейком).
  • Комментарий: Наиболее удачное место для хранения любых КВД. Однако, учитывая, что устройство может быть рутованным, все КВД должны быть зашифрованы дополнительно перед сохранением в Keychain. Кроме того, нужно с осторожностью использовать облачную синхронизацию из-за возможности автоматического сохранения Keychain в облаке. В случае, если приложение использует CloudKit, необходимо внимательно следить за данными, которые не должны синхронизироваться (если таковые имеются), и исключать их из набора копируемых данных.
  
  

Специфическая информация по платформе Android

Я слабо разбираюсь в платформе Android, поэтому нижеизложенный список — это краткое тезисное изложение базовых материалов, которые мне удалось найти по этой платформе:

• Наиболее удачным вариантом пользовательского кода является графический код, цифровой (6 цифр или более) — как дополнительный вариант.
• Запрос разрешений (permissions) на определенные виды активности приложения обязателен и должен выполняться явно для пользователя с разъяснением, для чего именно будет использовано разрешение. Запрашивать определенное разрешение нужно только в случае прямой необходимости его использования, также, запрос на разрешение нужно показывать именно в тот момент, когда оно понадобилось, не ранее. Кроме того, если целевая версия Android SDK равна 23 (или новее) — то следует проводить запрос разрешений только через систему разрешений совместимости (Compatibility Permissions System).
• HTTP-клиент должен быть настроен на принудительное использование защищенного канала связи (HTTPS).
• В релизной сборке приложения должны быть отключены все отладочные функции, например, опция debuggable, во избежание возможности подключения к программе внешним отладочным приложением.
• На экранах приложения, где размещается приватная информация пользователя, будет не лишним принудительный запрет на программное создание скриншотов окна приложения, а также отключение показа скриншотов в диспетчере задач.
• Любая приватная информация может дополнительно предваряться запросом личного ключа пользователя, заданного им для входа в приложение (если таковой имеется).
• Внутри кода приложения для резолвинга путей рекомендуется пользоваться getCanonicalPath вместо getAbsolutePath.
• Используемые в приложении открытые компоненты (например, Service или Content Provider) должны быть обязательно закрыты с помощью флага exported = false в манифесте приложения (Android Manifest). Это позволит запретить доступ к этим компонентам из другого приложения.

Кроме того, нужно с осторожностью использовать доступные хранилища информации:

Заключение

Также стоит упомянуть, что количество применяемых уровней защиты зависит от конкретного приложения. К примеру, если приложение вообще не является клиент-серверным, не содержит никаких КВД, а также не оперирует ценными внутренними алгоритмами, то вообще нет смысла навешивать на него какую-либо защиту. Если же приложение ориентировано, например, на выполнение банковских операций, или хранение пользовательских паролей, то степень его безопасности должна быть наивысшей. Однако перечисленные ранее общие уязвимости мобильного сектора достаточно легко могут быть исключены из приложения, чаще всего это не вносит особых дополнительных затрат, если применение требуемого уровня защиты было начато на ранних этапах разработки приложения. А вот внедрение защиты пост-фактум в уже работающее приложение вполне может быть сопряжено со значительными затратами сил и времени разработчиков. Поэтому выбор и согласование уровня защищенности, а также перечня КВД в разрабатываемом приложении, должны выполняться на самых ранних этапах проектирования.

рекомендации по безопасности / Intel corporate blog / Habr

Android – одна из самых популярных мобильных операционных систем в мире. Ей пользуются около полутора миллиардов человек. Но, несмотря на подобную распространённость, до некоторых пор в корпоративной среде эту ОС старательно избегали, опасаясь угроз безопасности.

Такая ситуация сложилась не случайно. В Android, до 5 версии, было множество уязвимостей. Теперь же Google всерьёз взялась за безопасность. Вдобавок к поддержке шифрования данных и автоматической блокировке экрана, в устройствах, работающих под управлением свежих версий Android, приложения ограничены в правах. Это способствует повышению уровня защищённости платформы.

Ещё одно важное улучшение в данной области представлено новой инициативой Google для организаций – Android for Work. В рамках Android for Work предлагается, во-первых – безопасность корпоративного уровня, во-вторых – возможность контейнеризации рабочих пространств, разделения рабочих и личных данных пользователей.

Эти улучшения серьёзно меняют дело, позволяя смело использовать Android-устройства в бизнес-среде. Естественно, при условии, что организации будут прилагать усилия к устранению проблем с безопасностью, присущих, в силу её особенностей, платформе Android. В этом материале мы рассмотрим четыре рекомендации по управлению Android-устройствами. А именно:

• Предотвращение получения пользователями повышенных привилегий на устройствах.
• Защита от мобильных вредоносных программ.
• Обязательное применение надёжных методов защиты информации.
• Реализация политик управления устройствами.

Предотвращение получения повышенных привилегий

В Android-среде взлом устройств с целью получения повышенных привилегий называют «рутованием». Это жаргонное, но весьма распространённое слово – русский вариант английского «rooting». Означает оно «получение прав суперпользователя», который в среде Unix-подобных ОС называется «root». Фактически это – снятие ограничений, накладываемых производителем на устройство, и получение полного доступа к нему. Пользователи взламывают телефоны и планшеты самостоятельно. Всё дело в том, что на рутованное Android-устройство можно устанавливать любые приложения, в том числе – потенциально опасные. Можно настраивать, на любом уровне, операционную систему, менять прошивку аппарата.
Приложение для получения прав суперпользователя на Lenovo Yoga Tablet

Рутованные устройства представляют серьёзную проблему безопасности для организаций. Эти устройства находятся в группе повышенного риска заражения вредоносным ПО. Работая в корпоративной сети, они могут быть причиной «утечек данных», могут сделать сеть уязвимой к хакерским атакам.

Проблема, связанная с получением пользователем повышенных привилегий, характерна не только для платформы Android. Так, например, в среде мобильных устройств от Apple существует термин «джейлбрейкинг». Он произошёл от англоязычного «jailbreak», что в дословном переводе означает «побег из тюрьмы». Джейлбрейкинг – это снятие стандартных ограничений на устройствах от Apple, работающих на iOS. В частности, таких, как iPhone, iPod touch, iPad, второе поколение Apple TV. Снятие ограничений заключается в программной или аппаратной модификации устройств, благодаря которому пользователь получает полный доступ к файловой системе iOS. Ему открываются новые возможности по настройке устройства, по установке приложений, расширений и тем, которые недоступны в Apple App Store. Однако в результате страдает безопасность и теряется гарантия на аппарат.

Для борьбы с рутованием рекомендовано запрещать подключение взломанных Android-устройств к корпоративной сети. Кроме того, полезно проводить с сотрудниками занятия по информационной безопасности. В частности, на таких занятиях стоит поднять тему того, какую угрозу рутованные устройства представляют для организации, и того, к каким последствиям могут привести утечка данных или их безвозвратная потеря.

Защита от мобильных вредоносных программ

Пользователи Android-устройств могут устанавливать приложения не только из Google Play, но и из других источников. Среди программ, установленных из ненадёжных источников, немало таких, которые несут в себе вредоносную составляющую. Риск установки вредоносного приложения, хотя и очень небольшой, благодаря политике безопасности Google, существует и при работе исключительно с Google Play. Это способно повлиять на организации, в которых работают пользователи, так как вредоносные программы могут красть логины и пароли для доступа к критически важным ресурсам, открывать доступ в корпоративные сети посторонним лицам, могут быть причиной потери важных данных.

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

• Dr.Web Antivirus
• Antivirus and Mobile Security (Avast)
• Mobile Security and Antivirus by ESET
• Armor for Android
• AntiVirus Security Free by AVG
• Mobile Security and AntiVirus by Avast
• Zoner AntiVirus Free
• BitDefender AntiVirus Free
• Hornet AntiVirus Free
• Norton Security Antivirus

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

Применение надёжных методов защиты информации

Если к корпоративной сети могут подключаться мобильные устройства – для защиты информации нужны надёжные меры безопасности. Конкретные подходы к обеспечению безопасности в разных организациях могут различаться, они зависят от специфики деятельности. Мы хотим предложить набор базовых рекомендаций, которые стоит включить в корпоративную политику управления мобильными устройствами.

• Пароли для доступа к ресурсам обязательно должны быть сложными.
• Нужно везде, где возможно, применять шифрование данных.
• Требуется контролировать использование приложений, основываясь на информации о подключении устройства к Wi-Fi-сетям предприятия, и, на основании политик доступа и сведений о примерном местоположении устройства, блокировать некоторые функции. В частности, к таким функциям относятся копирование и вставка данных, службы определения местоположения, электронная почта и приложения для обмена сообщениями, использование камеры и микрофона.

Обзор возможностей Google for Work

В дополнение к вышесказанному, здесь мы хотели бы сделать обзор возможностей Google for Work, которые основаны на передовых подходах к организации удобной и безопасной работы мобильных корпоративных пользователей.

Безопасность и разделение данных. При развёртывании Android for Work используется аппаратное шифрование и политики безопасности, управляемые администратором. Это позволяет разделить бизнес-данные и данные пользователя. Данные организации оказываются в безопасности, они защищены от вредоносного ПО. Информация пользователя при этом недоступна никому, кроме него.

Поддержка корпоративных устройств и личных устройств сотрудников. Пользователи Android for Work могут безопасно применять одно и то же устройство и для рабочих, и для личных целей. Компании могут предоставлять предварительно подготовленные корпоративные устройства работникам, а так же – настраивать рабочие профили на устройствах, которые принадлежат сотрудникам.

Удалённое управление. Администраторы могут удалённо управлять политиками безопасности, связанными с работой организации, приложениями и данными. Критически важные данные можно удалить с устройства дистанционно, при этом не затронув личных данных пользователя.

Удобная работа с личными и корпоративными приложениями. Android for Work позволяет создать однородную рабочую среду на всех устройствах. Личные и рабочие приложения находятся в одних и тех же списках установленных и недавно использованных приложений. Переключаться между разными видами приложений очень просто. К тому же, иконки для запуска рабочих приложений выделены особыми значками, которые чётко отличают их от личных приложений.

Упрощённая установка приложений. Администраторы могут использовать Google Play для поиска разрешённых в организации приложений, добавления их в белый список и для установки бизнес-приложений на устройства, работающие в системе Android for Work. Кроме того, Google Play можно использовать и для развёртывания собственных приложений компаний, предназначенных только для внутреннего использования. Подробнее об этом можно узнать в справочном центре Google Play for Work.

Отдельный набор приложений для работы. Пользователи, у которых нет Google Apps for Work, могут пользоваться полным набором безопасных рабочих приложений, специально созданных для применения в рамках Android for Work, но работающих и самостоятельно. В набор входят почтовая программа, календарь, записная книжка, список задач и менеджер загрузок.

Google предлагает систему Android for Work вместе с набором приложений Google Apps for Work. Всё это подходит для немедленного развёртывания. Система позволяет администраторам приложений пакета Google Apps for Work пользоваться функционалом корпоративного управления мобильными устройствами с помощью административной консоли. Это расширяет возможности по управлению устройствами.

Реализация политик управления устройствами

ИТ-служба компании должна иметь возможность централизованного управления Android-устройствами и их настройки. Рекомендовано выполнять дистанционную очистку потерянных или украденных устройств. Кроме того, очистку нужно проводить после некоторого количества неудачных попыток разблокировки смартфона или планшета. Весьма полезно организовать систему применения политик безопасности, основанную на местоположении устройства.

О безопасности в экосистеме Android

Google, работая над ОС Android и площадкой Google Play, стремится сделать экосистему Android безопаснее. Этой целью руководствуется команда Android Security, которая делает всё возможное для того, чтобы Android-устройства были как можно меньше подвержены угрозам.
Google применяет многоуровневый подход к безопасности. Первый уровень – это предотвращения самой возможности возникновения угрозы. Далее – это выявление вредоносных приложений и быстрая реакция при возникновении каких-либо проблем. А именно, вот что в Google делается ради повышения безопасности:

• Компания стремится предотвратить возникновение проблем с безопасностью. Делается это с помощью анализа архитектуры решений, тестирования систем на проникновение, аудита кода.
• До выпуска новых версий Android и Google Play проводится анализ безопасности.
• Исходный код Android открыт, доступен всем желающим. Как результат, его может анализировать большое сообщество разработчиков, выявляя проблемы и помогая сделать Android самой безопасной мобильной платформой в мире.
• Делается всё возможное для того, чтобы свести к минимуму последствия проблем с безопасностью. В частности, с помощью таких решений, как изолированная среда исполнения приложений.
• Приложения в Google Play проходят регулярную проверку на уязвимости и проблемы с безопасностью. Если приложение может представлять угрозу для устройств или данных, его удаляют с площадки.
• Ведётся плотная работа с партнёрами, направленная на как можно более быстрое устранение обнаруженных проблем с безопасностью и выпуск обновлений.

Команда разработки Android тесно сотрудничает с сообществом экспертов в области безопасности, обсуждая идеи, применяя в работе передовые решения, совершенствуя систему. Android является частью Google Patch Reward Program. Программа предусматривает вознаграждение для разработчиков, которые вносят вклад в повышение безопасности популярных проектов с открытым исходным кодом, многие из которых являются основой для Android Open Source Project (AOSP). Кроме того, Google является членом Forum of Incident Response and Security Teams (FIRST).

Заключение

Усилия Google сделали Android безопаснее, Android for Work позволяет взять под контроль мобильные устройства, которыми сотрудники пользуются для решения бизнес-задач. Однако не стоит забывать о том, что не существует абсолютно защищённых компьютерных систем.
На базе решений Google можно наладить безопасную работу Android-устройств в организации, но только в том случае, если будут учтены особенности такой работы, в том числе – человеческий фактор. Надеемся, этот материал поможет вам в построении безопасной мобильной рабочей среды.

Настройка защиты для Андроид устройств

Безопасность Android не должна восприниматься как должное. Будучи наиболее широко используемой платформой для смартфонов во всем мире, это заманчивая цель для злоумышленников и все пользователи должны следовать, по крайней мере, основным методам безопасности Android .

Люди, использующие устройства Android, сталкиваются с широким спектром угроз безопасности:

1. Потери данных
2. Кражи личных данных
3. Взломанных учетных записей
4. Скомпрометированной финансовой информации и даже кражи ваших Android-устройств

Учитывая широкий спектр настроек, почти невозможно охватить функции безопасности предлагаемые всеми ROM и шпионами Android. В этой статье рассматриваются функции безопасности в версии которая будет доступна в большинстве других ПЗУ.

Настройка функций безопасности Android

Мы перейдем от базовых настроек безопасности к более продвинутым настройкам по мере продвижения по этой статье.

# 1 Настройка блокировки экрана

Это базовый уровень безопасности для Android, который вы можете настроить для предотвращения физического доступа к вашему устройству. У вас есть следующие варианты выбора.

• Нет — блокировка устройства отсутствует.
• Проведите пальцем — Опять же, нет блокировки. Вам просто нужно прокрутить, чтобы перейти на главный экран.
• Шаблон — Настройте блокировку рисунка на устройстве. При настройке вам придется дважды нарисовать рисунок. Вы должны знать, что очень простые шаблоны можно просто понять, посмотрев на пятна на экране. Несколько перекрывающихся узлов могут затруднить распознавание начального и конечного узлов и сделать ваш шаблон более сложным. Вы можете обойти блокировку паттерна если вы заблокированы, но это решительный шаг и не рекомендуется брать на какое-либо устройство, которое не является вашим собственным.
• Pin — вы можете установить цифровой замок на устройстве. Длина замка не менее 4 цифр, но мы рекомендуем увеличить количество цифр. Как и обычные рекомендации по номерам контактов, не используйте дни рождения, юбилеи и другие даты личного значения в качестве штыря. В эпоху социальных сетей становится слишком легко узнать даты, которые важны для кого-то.
• Пароль — Настройте пароль для устройства длиной не менее 4 цифр. Пароли часто рекомендуются иметь длину 8 или более и эта мера предосторожности также применяется здесь. Вы можете использовать цифры и символы, чтобы сделать их более безопасными.

Мои личные предпочтения касаются блокировки шаблонов, поскольку они просты в использовании и обеспечивают достойный уровень безопасности Android. Посмотрите, что работает лучше всего для вас и настройте его!

# 2 Настройка доступа к отпечатку пальца (необязательно)

Если на вашем устройстве имеется считыватель отпечатков пальцев, вы можете настроить его как пароль для своего устройства. Являясь постоянным пользователем этой функции на своем S6, я бы сказал, что это самый удобный способ доступа к вашему устройству.

Для этого вы можете перейти к «Nexus Imprint» в разделе «Безопасность» и следовать экранным шагам, чтобы ваш отпечаток был зарегистрирован на устройстве. В следующий раз, когда вы захотите войти в систему, просто держите палец на читателе и вы в нем!

Когда это работает, это невероятно удобный способ доступа к устройству и обеспечивает безопасность вашего устройства Android.

# 3 Настройка Smart Lock

Функция Smart Lock позволяет настроить устройство для поиска определенных ситуаций и оставаться разблокированным. Вы можете включить или отключить функцию Smart Lock в меню «Настройки»> «Безопасность»> «Доверенные агенты» (в разделе «Дополнительно») . У вас есть следующие настройки для настройки смарт-блокировки.

 

• Обнаружение тела — Вы можете включить эту настройку, чтобы позволить устройству идентифицировать, когда вы его переносите и оставаться разблокированным. Он блокируется, когда вы не держите его в руках.
• Надежные места — Вы можете найти места на Картах Google, которые вы хотите считать «доверенными» и устройство останется там разблокированным.
• Доверенные устройства — Позвольте вашему устройству Android оставаться разблокированным в непосредственной близости от смартфонов, автомобилей или даже наклеек NFC. Обратите внимание, что для этой функции требуется Bluetooth.
• Надежное лицо — Используйте камеру на устройстве, чтобы распознать лицо авторизованных пользователей и разблокировать. Иногда такой способ может ошибаться и обычный PIN-код, шаблон или пароль станут более безопасным вариантом.
• Надежный голос —Для нормальной работы этой функции необходимо всегда использовать «OK Google». Вам нужно будет пройти процесс обучения, который устанавливает голосовую модель, соответствующую вашему голосу, прежде чем использовать эту функцию. Если распознавание голоса неточно, вы можете вернуться назад и обучить голосовую модель еще раз для большей точности.

# 4 Настройка администраторов устройств

Приложения требующие определенных специальных разрешений будут перечислены в разделе «Администраторы устройств». Нажмите на приложение, чтобы узнать какие разрешения оно запрашивает и хотите ли вы, чтобы это приложение могло иметь это разрешение.

Вам необходимо включить «Android Device Manger», поскольку он позволяет удаленно стереть и заблокировать ваше устройство  если оно украдено или потеряно.

Включение «Android Pay» в качестве администратора устройства будет налагать определенные ограничения на PIN-коды и пароли, которые вы можете использовать на устройстве.

Если вы используете Android Pay, мы рекомендуем вам добавить его в Администраторы устройств.

# 5 Включить шифрование

Включение шифрования на вашем устройстве Android гарантирует, что данные не находятся в читаемой форме, когда устройство заблокировано. Это отлично обеспечивает безопасности данных вашего Android-устройства. После его разблокировки данные дешифруются и используются.

Некоторые устройства, такие как мой Nexus 9, по умолчанию зашифрованы. Другие устройства могут иметь возможность включить его. Включите эту функцию для дальнейшего повышения безопасности Android.

# 6 Включить экранирование экрана

Вы можете использовать эту функцию, чтобы привязать текущий экран на своем устройстве пока не открепите. Вы можете запросить проверку пароля, когда экран не будет добавлен. Шаги по подключению экрана не являются наиболее интуитивными, хотя в качестве меры безопасности его можно использовать для ограничения доступа только к одному экрану вашего устройства.

Как подключить экран к Android-устройству?

1. Включить привязку экрана в разделе «Настройки»> «Безопасность»> «Экранное соединение».
2. Откройте экран, который вы хотите вывести.
3. Сенсорный Обзор (меню быстрого переключения приложений)
4. Проведите пальцем вверх и коснитесь значка pin-кода внизу

Как открепить закрепленный экран?

Одновременно нажмите кнопки «Назад» и «Обзор». Возможно, вам потребуется ввести шаблон, PIN-код или пароль для разблокировки в зависимости от ваших настроек.

Примечание. Фиксирование экрана может не ограничивать пользователя одним экраном, а скорее одним приложением. Например, привязка экрана безопасности в настройках Android позволяет мне перемещаться по всем настройкам, но не позволять мне это делать за пределами настроек.

# 7 Проверка доверенных учетных данных

Доверенные учетные данные используются приложениями и браузерами, обменивающимися через интернет для проверки подлинности сервера, с которым они соеденяются. Эти учетные данные не позволяют создать какой-либо другой сервер в качестве аутентичного сервера и гарантируют, что любые данные, отправляемые приложениями или браузерами, переходят по назначению.

Обычно вам не нужно входить в доверенные учетные данные и делать что-либо, особенно в разделе «Система». В разделе «Пользователь» перечислены учетные данные, которые вы могли бы добавить, если они есть. Вы должны убедиться, что учетные данные, добавленные вами вами, действительно заслуживают доверия.

# 8 Ограничение приложений с использованием доступа

Это приложения у которых есть разрешение контролировать использование вашего приложения на устройстве. Они могут отслеживать и регистрировать, какие приложения используются, когда и как долго и т. д. Обычно в этом списке будут сервисы Google Play и Play Store. Если вы не устанавливаете приложение для отслеживания вашего использования, никакие другие приложения не должны отслеживать его.

Если вы не хотите, чтобы у Google была такая информация, вы можете отказаться от доступа к данным об использовании.

# 9 Переключить некоторые настройки

1. Отключите «Сделать узор видимым», чтобы скрыть шаблон от посторонних глаз при разблокировке устройства.
2. Отключить «Сделать доступными пароли», чтобы они были скрыты при разблокировке устройства.
3. Отключить «Неизвестные источники», чтобы предотвратить загрузку приложений и APK ( что такое APK? ) Из других источников, кроме Play Store.
4. Включите «Кнопка питания мгновенно блокирует», чтобы немедленно заблокировать устройство при нажатии кнопки питания.

# 10 Другие меры безопасности для Android

Держите свою учетную запись Google в безопасности — Android-устройство защищено так же, как ваша учетная запись Gmail, связанная с устройством. Обеспечение безопасности вашей учетной записи Google поможет сохранить безопасность вашего смартфона. Кроме того, если вы заблокированы из своего устройства по какой-либо причине то можете использовать информацию учетной записи, чтобы проверить свою личность и разблокировать устройство.

Вам следует отключить параметры разработчика, если вы не используете устройство Android для разработки приложений.

Безопасность — программы для Android

• Родительский контроль

• Системная утилита

• Системная утилита

• Антивирусный софт

• Крутой антивирус

• Блокировка приложений

• Надежный антивирус

• Защита от кибер атак

• Вызов экстренной помощи

• Блокировка смартфона

• Антивирусный софт

• Блокировка контента

• Крутой антивирус

• Простенький антивирус

• Многофункциональный антивирус

• Карта Wi-Fi точек доступа с паролями

• VPN сервис от Symantec

• Беспроводная IP камера

• Защита смартфона от вирусов и воров

• Защита смартфона от краж

• Актуальная защита от вирусных угроз

• Анонимный серфинг по сети интернет

• Гид по интернет сайтам

• Антивирус + Keylogger

• Многофункциональный антивирус

• Проверка приложений на вирусы

• Мощный бесплатный антивирус

• Тотальный родительский контроль

• Контроль неприкосновенности смартфона

• Защита интернет серфинга

• Многофункциональный антивирусный комбайн

• Отменная защита от вирусов

• Защита приложений от посторонних глаз

• Ограничение доступа к приложениям

• Уникальный софт для защиты смартфона

• 100% защита от краж

• Лучший в мире VPN сервис

• Защита конфиденциальной информации

• Защита от шпионских программ и приложений

• Антивирусный комбайн

• Надежная защита от вирусов

• Многофункциональный Firewall

• Лучший бесплатный анти вор

• Лучший из лучших антивирусов

• Бесплатный антивирус

• Удаление вредоносного ПО

• Бесплатный многофункциональный антивирус

• Многофункциональный антивирус

• Самый популярный антивирус

• Блокировка информации от посторонних глаз

• Один из лучших антивирусов для Android

• Отменный бесплатный антивирус

• Антивирусный комбайн

• Самый продвинутый рекламный фильтр

• Самый лучший антивирус года

• ← Сюда
• 1
• 2
• Туда →

Хоть многие и считают, что антивирусы на Android вовсе не нужны, но большинство других пользователей предпочитают заботиться про безопасность своего устройства, используя специальные программы на Android, которые, к слову, вы сможете скачать здесь совершенно бесплатно. Каждый антивирус по своему хорош: какой-то меньше занимает ОЗУ, какой-то больше. Один может выполнять поиск в основном среди приложений, а другой и файлы ваши проверит, и приложения, да и про системные разделы также не забудет. Не следует забывать, что если автоматическая проверка всегда будет сильно влиять на батарею, поэтому совет на все века — читайте комментарии пользователей, особенно на странице Google Play. А за качество антивирусов можете не переживать, т.к. в данном разделе публикуются только качественные антивирусы от компаний, которые действительно связаны с информационной безопасностью и имеют собственные наработки в данной области.

В Android 4.4.2 удалили ключевую функцию безопасности / Habr

Фонд электронных рубежей (EFF) буквально позавчера выразил одобрение исключительно важной с точки зрения безопасности функцией, которая появилась в Android 4.3: настройка индивидуальных разрешений для каждого приложения. В настройке App Ops можно запретить/разрешить каждому приложению фиксировать номер IMEI, собирать геолокационные данные, читать адресную книгу и прочее. Эту функцию давно просили реализовать в Android — и её появление стало большим событием.

К сожалению, с выпуском апдейта Android 4.4.2 решено отменить сделанные изменения — и раздел App Ops просто исчез из настроек. Компания Google заявила, что функция была выпущена «по ошибке».

Апдейт Android 4.4.2 вышел на этой неделе, в нём возможность настройки разрешений отсутствует как таковая.

Фонд электронных рубежей обратился за комментарием в компанию Google и получил неожиданный ответ. Оказывается, эту функцию вообще не планировали выпускать, она была экспериментальной и попала в финальный релиз случайно. Изменение разрешений для некоторых приложений способно нарушить их работу, поэтому для обеспечения цельности системы экспериментальную функцию удалили с апдейтом Android 4.4.2.

Фонд электронных рубежей с подозрением воспринял такое объяснение. Они считают, что оно не может быть оправданием для удаления полезной функции вместо того, чтобы улучшить её работу. «Во многих случаях «поломку» приложения при установке запрета на геолокацию, чтение адресной книги или IMEI можно легко исправить, например, подав приложению фальшивые координаты, пустую адресную книгу или номер IMEI, состоящий из нулей, — сказано в заявлении EFF. — Как вариант, компания Google могла внести в документацию для разработчиков пункт, что такие вызовы API могут не работать по причинам приватности, так что программа должна предусмотреть исключение на этот случай. Хорошим компромиссным вариантом было бы использование фальшивых данных для старых версий Android API и чётко определённых исключений в следующих версиях API. Как и с другими изменениями в Android-устройствах и новых версиях ОС, некоторые разработчики просто внесут незначительные изменения в код программ».

EFF считает, что исчезновение функции из операционной системы Android — очень тревожный знак. Отсутствие такой функции представляет собой дыру в безопасности устройств, которыми пользуются более миллиарда человек. Удивительно, что даже Apple решила эту проблему в iOS несколько лет назад.

«Совсем недавно казалось, что Google позаботилась об этой массовой проблеме с приватностью, — пишет EFF. — Теперь у нас появились сомнения. Единственным способом развеять сомнения для Google является немедленно вернуть интерфейс App Ops, а также доработать его и дополнить фундаментально важными частями». Вот что следует добавить.

• Возможность отключить функции слежения (телефонные номера, IMEI, другая информация об аккаунтах) для всех приложений сразу.
• Возможность полного отключения доступа в интернет для отдельных приложений. Очевидно, что многим приложениям, таким как фонарик, обои, скины интерфейса, многие игры, просто не нужен доступ в интернет, а злоумышленники пользуются этой уязвимостью.
• Интерфейс App Ops должен быть улучшен и правильно интегрирован в основной интерфейс ОС, в том числе в раздел «Настройки» – «Приложения» и в интерфейс Play Store.

Фонд электронных рубежей рекомендует обычным пользователям, которые заботятся о сохранности личной информации, пока воздержаться от обновления на Android 4.4.2. Хотя, в том же апдейте закрывается ряд дыр в безопасности, так что каждому придётся сделать личный выбор между приватностью и безопасностью.

«Google, правильные действия в такой ситуации очевидны», — обращается с призывом Фонд электронных рубежей.