Рекомендации по обеспечению безопасности системы

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

Биометрическая аутентификация

Тщательно собирайте, храните и обрабатывайте биометрические данные для аутентификации пользователей. Вам следует:

  • Обязательно укажите основной метод аутентификации, прежде чем использовать любую другую форму аутентификации (включая биометрию).
  • Требовать явного подтверждения для указания намерения при использовании пассивных биометрических методов, таких как распознавание лиц, для транзакций (например, платежей), в которых используются ключи, привязанные к аутентификации.
  • Требовать основной метод аутентификации каждые 72 часа.
  • Используйте полностью безопасный конвейер для всех биометрических данных и их обработки.
  • Никогда не отправляйте биометрические данные (включая необработанные измерения датчиков и производные функции) за пределы устройства. Если возможно, храните эти данные в безопасной изолированной среде, например в доверенной среде выполнения (TEE) или Secure Element.

Устройства с биометрическими данными должны поддерживать API BiometricPrompt , который предлагает общий и согласованный интерфейс, позволяющий разработчикам приложений использовать преимущества аутентификации на основе биометрии в своих приложениях. Только надежная биометрия может интегрироваться с BiometricPrompt , и интеграция должна соответствовать рекомендациям документа определения совместимости Android (CDD).

Дополнительные рекомендации по биометрии см. в разделе Рекомендации по внедрению биометрического HAL .

SELinux

SELinux обеспечивает определение и реализацию большей части модели безопасности Android. Правильное использование SELinux имеет решающее значение для безопасности устройств Android и может помочь смягчить влияние уязвимостей безопасности. По этой причине все устройства Android должны реализовать надежную политику SELinux .

  • Внедрите политику наименьших привилегий.
  • Не предоставляйте разрешения CAP_DAC_OVERRIDE , CAP_SYS_ADMIN и CAP_NET_ADMIN .
  • Не записывайте системные данные на SD-карту.
  • Используйте предоставленные типы для доступа к драйверам, такие как gpu_device , audio_device и т. д.
  • Используйте осмысленные имена для процессов, файлов и типов SELinux.
    • Убедитесь, что метки по умолчанию не используются и к ним не предоставлен доступ.
  • Политика, специфичная для устройства, должна составлять 5–10 % от общей политики, действующей на устройстве. Настройки в диапазоне 20%+ почти наверняка содержат домены с чрезмерными привилегиями и мертвую политику. Неоправданно большая политика тратит память, дисковое пространство из-за необходимости создания загрузочного образа большего размера и отрицательно влияет на время поиска политики во время выполнения.

Динамическая загрузка политики SELinux

Не загружайте политику SELinux динамически на устройствах Android. Это может привести к таким проблемам, как:

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

Бэкдоры

Приложения Android не должны иметь бэкдоров или способов доступа к системе или данным в обход обычных механизмов безопасности. Сюда входит специальный доступ к диагностике, отладке, разработке или гарантийному ремонту, закрытый секретами, известными разработчику. Чтобы предотвратить бэкдоры:

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

Инструменты разработки

Инструменты разработки, такие как инструменты отладки, тестирования и диагностики, часто могут создавать непреднамеренные бреши в безопасности вашего устройства, раскрывая принцип их работы и данные, которые они собирают. Чтобы убедиться, что инструменты разработки не попали в рабочие сборки:

  • Создайте черный список хэшей собственных инструментов отладки и тестирования и просканируйте сборки этих APK-файлов перед использованием образа системы.
  • Сканируйте все сторонние приложения с помощью признанного в отрасли инструмента сканирования уязвимостей приложений.
  • Наймите стороннюю фирму по тестированию безопасности приложений, чтобы оценить все критически важные диагностические приложения на устройстве перед любым крупным обновлением, особенно если приложение разработано третьей стороной.
  • Убедитесь, что только пользователь может включить инструмент устно или в чате во время сеанса поддержки. Сохраните артефакты согласия и отключите инструмент после сбора необходимой диагностической информации.
  • Сохраняйте записи об использовании этого инструмента в журнале, доступном пользователю в его учетной записи оператора связи.
  • Убедитесь, что любая личная информация (PII) или данные телеметрии устройства, собранные с помощью инструмента, подлежат анонимизации, сохранению и удалению, применимым к стране. Следует собирать только данные, относящиеся к обращению в службу поддержки. Эти данные следует удалять после каждого звонка.
  • Убедитесь, что методы, которые можно использовать для шпионского ПО, такие как регистрация нажатий клавиш, использование микрофона или камеры, не используются без явного согласия пользователя. Приложения, использующие эти потенциально нарушающие конфиденциальность методы, должны быть очень четко раскрыты вместе с политикой конфиденциальности, с которой пользователь должен согласиться. Подобные приложения не следует включать без явного согласия пользователя.

Вот несколько дополнительных рекомендаций, на которые следует обратить внимание при реализации раскрытия информации и согласия:

Раскрытие информации в приложении

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

Встроенная функциональность в AOSP

Встраивание дополнительных функций в AOSP часто может иметь неожиданное поведение и последствия; действовать с осторожностью.

  • Убедитесь, что пользователю будет предложено использовать другие приложения по умолчанию (например, поисковую систему, веб-браузер, программу запуска) и раскрыть отправку данных с устройства.
  • Убедитесь, что APK-файлы AOSP подписаны сертификатом AOSP.
  • Запускайте регрессионные тесты и ведите журнал изменений, чтобы определить, был ли добавлен код в APK-файлы AOSP.

Обновления безопасности

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

  • Работайте с партнерами по оборудованию, такими как поставщики ваших SoC, чтобы заключить соответствующие соглашения о поддержке для всех компонентов вашего устройства Android.
  • Убедитесь, что обновления безопасности могут быть установлены с минимальным взаимодействием с пользователем, чтобы повысить вероятность того, что пользователи примут и установят обновления на свое устройство Android. Настоятельно рекомендуется внедрить бесшовные обновления системы или аналогичную функцию безопасности.
  • Убедитесь, что вы понимаете совокупные требования к уровню обновлений безопасности Android (SPL), указанные в Бюллетене по безопасности Android . Например, устройства, использующие уровень исправлений безопасности от 2018-02-01, должны включать в себя все проблемы, связанные с этим уровнем исправлений безопасности, а также исправления всех проблем, о которых сообщалось во всех предыдущих бюллетенях по безопасности.

Динамические обновления ядра

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

Ключевой менеджмент

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

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

Подписание образа системы

Подпись образа системы имеет решающее значение для определения целостности устройства.

  • Не подписывайте устройства общеизвестным ключом.
  • Управляйте ключами подписи устройств в соответствии со стандартными отраслевыми практиками обработки конфиденциальных ключей, включая аппаратный модуль безопасности (HSM), который обеспечивает ограниченный, проверяемый доступ.

Разблокируемые загрузчики

Многие устройства Android поддерживают разблокировку, что позволяет владельцу устройства изменить системный раздел или установить собственную операционную систему. Общие случаи использования включают установку стороннего образа системы и выполнение разработки на уровне системы на устройстве. Например, чтобы разблокировать образ системы на Google Nexus или Pixel, пользователь может запустить fastboot oem unlock , при этом отобразится такое сообщение:

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

  • После того, как пользователь подтвердит команду разблокировки, устройство должно начать немедленную очистку данных. Флаг unlocked не должен устанавливаться до завершения безопасного удаления.
  • Если безопасное удаление невозможно завершить, устройство должно оставаться в заблокированном состоянии.
  • Если это поддерживается базовым блочным устройством, следует использовать ioctl(BLKSECDISCARD) или его эквивалент. Для встроенных устройств MultiMediaCard (eMMC) это означает использование команд безопасного стирания или безопасной обрезки. Для eMMC 4.5 и более поздних версий это означает использование обычного стирания или обрезки с последующей операцией очистки.
  • Если BLKSECDISCARD не поддерживается базовым блочным устройством, вместо него необходимо использовать ioctl(BLKDISCARD) . На устройствах eMMC это обычная операция обрезки.
  • Если BLKDISCARD не поддерживается, допустима перезапись блочных устройств нулями.
  • У пользователя должна быть возможность потребовать стереть пользовательские данные перед перепрограммированием раздела. Например, устройства Nexus используют команду fastboot oem lock для стирания пользовательских данных.
  • Устройство может записывать с помощью eFuses или аналогичного механизма, было ли устройство разблокировано и/или повторно заблокировано. Однако мы настоятельно рекомендуем, чтобы повторная блокировка загрузчика с последующим сбросом настроек восстановила полную функциональность устройства.

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

Разблокированное устройство можно впоследствии повторно заблокировать с помощью команды fastboot oem lock . Блокировка загрузчика обеспечивает такую ​​же защиту пользовательских данных в новой пользовательской ОС, как и в исходной ОС производителя устройства (например, пользовательские данные будут удалены, если устройство снова разблокируется).

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

Перед отправкой устройства должны быть проверены компетентным пентестером. Тестирование на проникновение должно установить, что устройство соответствует рекомендациям по безопасности, представленным здесь, а также внутренним рекомендациям по безопасности OEM.

Тестирование безопасности

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

  • Используйте инструменты безопасности памяти во время разработки: используйте MTE там, где это поддерживается (ARMv9 и выше), и HWAsan там, где это не поддерживается. Запустите как можно больше тестов с включенными этими инструментами.
  • Используйте GWP-ASan и KFENCE в производстве для вероятностного обнаружения проблем безопасности памяти.