Защита корпоративных устройств Android: разбор уязвимостей сентября 2026

Google закрыла 180 уязвимостей Android: что произошло

В сентябре 2026 года Google выпустила давно ожидаемое обновление безопасности Android — предыдущий патч выходил почти двумя месяцами раньше. Новый пакет устраняет 180 уязвимостей сразу, и это веский повод пересмотреть защиту корпоративных устройств: часть найденных проблем позволяет злоумышленнику удалённо выполнить код на смартфоне без каких-либо действий его владельца.

Обновление разбито на два уровня патчей. Уровень от 2026-09-01 закрывает 95 уязвимостей в базовых системных компонентах: Android Runtime, Framework, System, Setup Wizard и модулях Project Mainline. Больше всего проблем нашлось в компоненте System — 56 штук, из них 23 критические (позволяют удалённо выполнить код, повысить привилегии или вызвать отказ в обслуживании). Framework получил 37 исправлений (3 критических), Android Runtime — одно.

Второй патч-уровень, датированный 2026-09-05, добавляет ещё 85 исправлений — на этот раз в ядре Android и в компонентах от производителей чипов и периферии: Arm, Qualcomm, MediaTek, Unisoc, Imagination Technologies, Tsingteng Micro и других. Отдельно эксперты выделяют CVE-2026-28662 — уязвимость повреждения памяти в модуле Wi-Fi, которая допускает удалённое выполнение кода без каких-либо привилегий и вообще без действий пользователя. Для Wear OS, Android XR и Android Automotive OS Google отдельных бюллетеней не выпустила, но соответствующие правки вошли в общий пакет обновлений.

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

Бизнесу важно не абсолютное число уязвимостей, а то, что часть из них эксплуатируется вовсе без действий сотрудника. Специалисты по ИБ привыкли снижать риск фишинга и социальной инженерии через обучение персонала: не переходить по подозрительным ссылкам, не устанавливать сомнительные приложения. Но перед уязвимостью вроде CVE-2026-28662 такие меры не работают — устройство может оказаться скомпрометированным просто из-за того, что попало в радиус действия Wi-Fi рядом со злоумышленником.

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

Кого касается проблема: BYOD, MFA-приложения и удалённый доступ

В большинстве компаний Android-смартфон сотрудника давно перестал быть просто личным гаджетом — он стал частью периметра информационной безопасности. С него подключаются к корпоративной почте по ActiveSync, поднимают VPN-туннель для удалённого доступа к инфраструктуре, получают push-уведомления от приложений двухфакторной аутентификации. Опасность компрометации одного смартфона не в самом устройстве, а во всей цепочке доступа, которую оно открывает.

• Компании с политикой BYOD, где личные Android-устройства сотрудников используются для рабочей почты и мессенджеров
• Организации, у которых вторым фактором для входа в VPN, RDG или корпоративные порталы служит только push-уведомление либо одноразовый код мобильного приложения
• Компании, выдающие сотрудникам корпоративные Android-смартфоны и планшеты, но не контролирующие их обновления централизованно
• Организации, где пользователи с расширенными правами — ИТ-администраторы, бухгалтерия, топ-менеджмент — заходят в критичные системы именно с мобильных устройств

Что именно закрыли патчи 2026-09-01 и 2026-09-05

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

Первоочередные шаги для бизнеса после сентябрьского патча Android

1. Обновить весь парк корпоративных Android-устройств до уровня патча 2026-09-05 и выше через систему управления мобильными устройствами (MDM/UEM) — не полагаясь на то, что сотрудник справится с этим сам.
2. Сверить фактический патч-левел устройств в консоли UEM и найти смартфоны без обновления — как правило, это устаревшие модели, снятые производителем с поддержки.
3. Для BYOD-устройств, которые нельзя обновить централизованно, временно ограничить доступ к корпоративным ресурсам до установки патча — например, заблокировать вход в VPN и почту с непропатченных прошивок.
4. Проверить, на чём основан второй фактор аутентификации: если это push-уведомление мобильного приложения, для критичных систем и привилегированных учётных записей стоит выбрать более надёжный способ подтверждения входа.
5. Отдельно взять под контроль привилегированный доступ: администраторам и другим пользователям с расширенными правами, работающим с мобильных устройств, стоит сузить перечень операций, доступных с непроверенных или устаревших прошивок.

Защита корпоративных устройств: что входит в это понятие

История с сентябрьским патчем Android — лишь частный случай более широкой задачи, стоящей перед любой службой информационной безопасности. Речь не о разовой установке антивируса или контроле одного вида гаджетов, а о системе, охватывающей весь парк конечных точек, через которые сотрудники обращаются к рабочим ресурсам: рабочие станции и ноутбуки на Windows и Linux, корпоративные и личные смартфоны и планшеты на Android и iOS, а в ряде отраслей — ещё и терминалы, кассовую технику и другое оборудование на периметре сети.

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

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

Какие угрозы актуальны для конечных устройств бизнеса

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

• Уязвимости в ОС и прошивках устройств — как в разобранном выше случае, когда заражение происходит без какого-либо участия пользователя;
• Фишинг и социальная инженерия — остаются одним из самых частых способов первичного проникновения в корпоративную сеть независимо от того, насколько свежая версия ОС стоит на устройстве;
• Компрометация учётных данных — подбор либо кража пароля, перехват сессии, вход под чужой учётной записью с заражённого или неучтённого устройства;
• Вредоносное ПО и нежелательные приложения, установленные в обход политик безопасности, — характерная проблема BYOD-устройств вне централизованного контроля;
• Внутренние угрозы и человеческий фактор — включают не только умышленные действия инсайдеров, но и обычные ошибки персонала: пересылку конфиденциальных файлов на личную почту, утерю незашифрованного устройства, работу с рабочими документами в непроверенных приложениях;
• Атаки через удалённый доступ — перехват или подмена VPN-сессии, попытки входа в RDG, VPN или ADFS по украденным либо подобранным учётным данным;
• Избыточные привилегии — учётные записи администраторов и других пользователей с расширенными правами создают повышенный риск, если доступ к ним не разграничен и не журналируется отдельно.

Ни один из этих векторов не закрывается одним-единственным инструментом: своевременное обновление прошивок снижает риск атак вроде CVE-2026-28662, но никак не защищает от кражи пароля администратора или утечки файла через личный мессенджер сотрудника. Поэтому на практике защита корпоративных устройств складывается из нескольких классов решений — каждое отвечает за свой участок периметра.

Классы решений для защиты конечных устройств: как выбрать

При выборе инструментов важно понимать: антивирус, EDR, DLP, MDM/UEM, VPN и системы управления привилегированным доступом закрывают разные задачи и почти никогда не подменяют друг друга полностью. Ниже сведены основные классы решений — какие угрозы они снимают и когда особенно нужны.

На практике большинству компаний нужен не один класс решений, а их сочетание: базовый антивирус закрывает массовые угрозы, MDM/UEM даёт видимость патч-левела парка мобильных устройств (что было бы принципиально важно в истории с сентябрьским обновлением Android), MFA прикрывает точки входа от компрометации пароля, а PAM и DLP снимают риски, связанные с привилегированными пользователями и утечками данных.

BYOD: как защитить рабочие данные на личных устройствах сотрудников

Политика BYOD (Bring Your Own Device) даёт компании экономию на закупке техники, но усложняет защиту корпоративных устройств: ИТ-отдел не может управлять личным смартфоном сотрудника так же напрямую, как корпоративным, а сам сотрудник, как правило, не хочет, чтобы работодатель получил доступ к его личным фото, переписке и приложениям.

Решение — разграничивать личные и рабочие данные на одном устройстве, не беря под контроль весь гаджет. На практике это реализуется через контейнеризацию рабочих приложений: почта, документы и корпоративные мессенджеры функционируют в изолированном профиле с отдельным подтверждением доступа, а профили MDM/UEM распространяют требования безопасности — обязательный пароль, шифрование, минимальный уровень патча — только на рабочий контур устройства, не затрагивая личные данные сотрудника.

Отдельный вопрос — реагирование на инциденты с BYOD-устройствами. Если сотрудник теряет личный смартфон с настроенной рабочей почтой, компании нужна возможность удалённо стереть именно корпоративный контейнер, не трогая личные данные владельца. Такая избирательная очистка (selective wipe) есть в стандартном функционале большинства MDM-решений и отличает продуманную BYOD-политику от простого запрета личных устройств — запрета, который сотрудники на практике всё равно обходят.

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

Защита удалённого доступа: VPN и переход к Zero Trust

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

Модель Zero Trust устраняет это ограничение: вместо доверия по факту подключения к сети каждый запрос к каждому ресурсу проверяется отдельно — с учётом личности пользователя, состояния устройства (в том числе актуальности патчей) и контекста обращения. Для бизнеса переход к Zero Trust не обязательно означает отказ от VPN — чаще он происходит поэтапно: VPN остаётся точкой входа, доступ внутри сети сегментируется, а критичные системы дополнительно защищаются многофакторной аутентификацией и отдельным контролем привилегированных сессий.

Какая бы модель ни применялась, точки удалённого подключения — сам VPN, шлюз удалённых рабочих столов (RDG), федеративная аутентификация через ADFS — нуждаются в защите вторым фактором. Даже сложный пароль не спасает от фишинга и утечек баз данных других сервисов, где сотрудник мог использовать похожую пару логин-пароль; именно этот пробел закрывает MFA, требуя дополнительного подтверждения личности при входе.

Управление доступом: от найма до увольнения сотрудника

Ещё один источник риска для защиты корпоративных устройств и систем — не сама техника, а то, как компания управляет правами доступа на протяжении всего жизненного цикла сотрудника. Учётные записи, оставшиеся активными после увольнения, избыточные права, накопленные за годы смены должностей, доступ, выданный подрядчику под конкретный проект и вовремя не отозванный, — типовые находки практически любого аудита ИБ.

Закрыть этот пробел помогает управление доступом по жизненному циклу сотрудника: при приёме на работу учётная запись и права формируются по заранее заданному шаблону для конкретной должности, при смене роли права пересматриваются, а при увольнении отзываются полностью и сразу — включая доступ к почте, VPN, корпоративным приложениям и мобильным устройствам, а не только к основной учётке в домене.

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

Мониторинг устройств, реагирование на инциденты и аудит ИБ

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

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

Ещё один элемент такой защиты — регулярный аудит ИБ и обследование инфраструктуры, особенно значимый для организаций, подпадающих под требования к критической информационной инфраструктуре (КИИ). Такой аудит нужен не только для формального подтверждения соответствия требованиям регуляторов, но и для того, чтобы на практике найти устройства и учётные записи, выпавшие из-под контроля политик, — например, старые смартфоны без поддержки обновлений, о которых говорилось выше в разборе сентябрьского патча Android.

Нормативные требования: 152-ФЗ, КИИ и реестр отечественного ПО

Для многих организаций забота о безопасности корпоративной техники — не только практическая необходимость, но и обязательство перед регуляторами. Если на устройствах обрабатываются персональные данные сотрудников или клиентов, компания обязана соблюдать требования 152-ФЗ «О персональных данных» — в том числе принимать меры, соразмерные актуальным угрозам, для защиты таких данных на всех устройствах, где они обрабатываются или хранятся.

Организации, относящиеся к субъектам критической информационной инфраструктуры (КИИ) — в частности, компании из энергетики, транспорта, связи, финансового сектора и ряда других отраслей, — дополнительно подпадают под действие 187-ФЗ и обязаны выполнять конкретные меры защиты значимых объектов КИИ, включая защиту оконечных устройств, через которые к этим объектам осуществляется доступ.

Требования к средствам защиты информации на территории России устанавливают ФСТЭК и ФСБ России — от них зависит, какие классы решений допустимо применять для защиты значимых объектов КИИ и персональных данных определённого уровня защищённости. При выборе конкретных продуктов стоит проверять наличие сертификатов соответствия требованиям этих регуляторов, а также статус решения в реестре отечественного программного обеспечения — это особенно важно для компаний с госучастием и для организаций, на которые распространяются требования по импортозамещению.

Чек-лист: первые шаги в защите корпоративной техники компании

Если система защиты конечных устройств в компании ещё не выстроена, начинать разумнее не с покупки конкретного продукта, а с инвентаризации и расстановки приоритетов по рискам.

1. Провести полную инвентаризацию устройств, имеющих доступ к рабочим ресурсам, — включая личные смартфоны сотрудников по BYOD и технику подрядчиков;
2. Определить устройства с доступом к самым чувствительным данным и системам — персональным данным, финансовой информации, коммерческой тайне — и защитить в первую очередь именно их;
3. Внедрить MDM/UEM для контроля патч-левела и состояния устройств, в первую очередь мобильных, — без этого трудно быстро понять, какие гаджеты остались уязвимы после очередного обновления безопасности вроде сентябрьского патча Android;
4. Включить многофакторную аутентификацию на всех точках входа — Windows, VPN, RDG, ActiveSync, ADFS, — начав с учётных записей с повышенными привилегиями;
5. Настроить разграничение доступа по ролям и жизненному циклу сотрудника, чтобы права автоматически назначались и отзывались при приёме, переводе и увольнении;
6. Взять под отдельный контроль привилегированный доступ администраторов и подрядчиков с помощью PAM-решений, обеспечив журналирование и ограничение сессий;
7. Настроить мониторинг действий персонала и событий безопасности, чтобы выявлять нетипичное поведение раньше, чем оно обернётся утечкой или инцидентом;
8. Зафиксировать и регулярно пересматривать политику BYOD — какие устройства допускаются, какие данные на них можно хранить и что делать при утере гаджета;
9. Провести аудит ИБ и сверить принятые меры с требованиями регуляторов, применимыми к компании, — 152-ФЗ, а для субъектов КИИ — ещё и 187-ФЗ.

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

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

Что такое 0-click уязвимость и чем она отличается от обычной?

Эксплуатация 0-click уязвимости — как в случае CVE-2026-28662 — не требует перехода по ссылке, открытия файла или установки приложения: заражение происходит без каких-либо действий владельца устройства. Обучение сотрудников цифровой гигиене от таких атак не защищает — единственный работающий барьер — своевременная установка обновлений.

Как узнать, что корпоративные Android-устройства защищены от найденных уязвимостей?

Нужно проверить уровень патча безопасности в настройках устройства либо, если парк подключён к UEM/MDM, свериться с отчётом о патч-левеле в консоли управления. Устройства с уровнем ниже 2026-09-05 остаются уязвимы к части найденных ошибок.

Может ли компрометация смартфона сотрудника повлиять на корпоративный VPN или почту?

Да. Если на смартфоне настроены VPN-туннель, подключение к RDG или почта через ActiveSync, а также установлено приложение двухфакторной аутентификации, компрометация устройства открывает злоумышленнику доступ ко всей этой цепочке, а не только к личным данным владельца.

Что делать, если в компании принята политика BYOD и обновить все устройства централизованно нельзя?

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

Затронуты ли Wear OS, Android Automotive и Android XR?

Отдельных бюллетеней для этих платформ Google не публиковала, но нужные исправления включены в общий пакет сентябрьских обновлений — устройства на этих версиях тоже стоит обновить.

С каких устройств лучше начинать защиту корпоративных устройств, если раньше системного подхода не было?

Логичнее начать с устройств, имеющих доступ к самым чувствительным данным и системам, — рабочих станций бухгалтерии, ноутбуков и смартфонов руководства и ИТ-администраторов, а также техники, открывающей удалённый доступ к инфраструктуре. Именно на этом контуре стоит сначала внедрить MFA, разграничение привилегированного доступа и контроль патч-левела, а затем постепенно распространять эти меры на остальной парк устройств, включая BYOD.

Нужен ли отдельный DLP, если в компании уже есть антивирус и MDM?

Антивирус и MDM отвечают за разные задачи: один борется с вредоносным ПО, другой управляет устройствами и патчами. Ни тот, ни другой не следят за тем, куда сотрудник пересылает файлы с конфиденциальными данными — на личную почту, в облако или на внешний носитель. Если компания работает с персональными данными, финансовой информацией или коммерческой тайной, этот риск закрывает именно DLP — ни антивирус, ни MDM его не покрывают.

Обязательно ли использовать Zero Trust вместо VPN?

Нет, эти подходы не взаимоисключающие. Многие компании сохраняют VPN как точку входа, дополняя его принципами Zero Trust — сегментацией доступа внутри сети, проверкой состояния устройства, многофакторной аутентификацией для критичных систем. Полный переход на архитектуру Zero Trust — отдельный проект, который лучше планировать поэтапно, а не как единовременную замену VPN.

Итог: обновление патчей — часть защиты корпоративных устройств, а не разовая задача

Сентябрьский патч Android 2026 года — больше, чем рядовое обновление. 180 закрытых уязвимостей, включая критическую ошибку удалённого выполнения кода без каких-либо действий пользователя, наглядно доказывают: защита корпоративных устройств не может держаться исключительно на осведомлённости персонала. Нужен централизованный контроль версий прошивки, видимость патч-левела всего парка техники и возможность оперативно ограничивать доступ устройствам, отстающим по обновлениям.

Управление доступом с мобильных и удалённых устройств, контроль привилегированных пользователей, многофакторная аутентификация для VPN, RDG, ADFS и корпоративной почты — это задачи, которые правильнее решать не разовыми инструкциями для сотрудников, а на уровне политик доступа. Мы, как партнёр СКБ Контур, помогаем настроить такие сценарии — от удалённого подключения и UEM до MFA и контроля привилегированного доступа — под конкретную инфраструктуру заказчика с помощью Контур.Эгиды.