Ексклюзив: Google планує скоротити оновлення безпеки для Android Enterprise Рекомендовано

У той час як Android є загальною домінуючою операційною системою для смартфонів згідно з даними IDC, iOS від Apple є ОС для більшості підприємств. Легко зрозуміти чому: Apple оновлює свої пристрої iOS, як правило, набагато довше та послідовніше, ніж більшість виробників пристроїв Android оновлювати свої смартфони, iPhone прості в налаштуванні та керуванні, і є набагато менше SKU для підтримки, якщо компанія вибере Яблуко. Але є також причини для підприємств вибирати пристрій Android, зокрема зниження вартості та більша гнучкість апаратного забезпечення. Щоб зробити Android ще більш привабливим для робочого місця, Google запустив «Android for Work» на початку 2015 року (пізніше перейменований на «Android Enterprise» наприкінці 2016 року). Потім на початку 2018 року Google запустив Програма Android Enterprise Recommended (AER). для сертифікації пристроїв для комерційного використання. Google кодифікував набір вимог, яким мають відповідати пристрої, щоб отримати статус «Рекомендовано для Android Enterprise», зокрема мінімальні специфікації апаратного забезпечення, підтримку масового розгортання, доступність розблокованих пристроїв, узгодженість поведінки програми, що працює в керованих профілях, і доставка оновлень безпеки Android протягом 90 днів після випуску для мінімум трьох років.

Однак документи, виявлені розробником Android @deletescape які були переглянуті XDA-розробники повідомляють, що Google планує послабити вимоги до оновлень безпеки для рекомендованих пристроїв Android Enterprise. Натомість Google наполягає на тому, щоб постачальники були більш прозорими щодо того, як вони обробляють оновлення безпеки. Згідно з @deletescape, ці документи були надані постачальникам протягом останніх 15 днів. Таким чином, хоча ми не можемо гарантувати, що ці запропоновані зміни в Android Enterprise Recommended внесуть свій шлях в остаточний список вимог, ми можемо принаймні підтвердити, що Google нещодавно врахував їх зміни.

Наразі є 170 різних пристроїв Android які рекомендовано Android Enterprise. HMD Global, Sony, Motorola, OPPO, і звичайно, Google, пропонують пристрої, які є AER. Навіть OnePlus розглядає можливість сертифікації своїх пристроїв за програмою. Однак відомі бренди споживчих смартфонів — не єдині компанії, які продають рекомендовані пристрої Android Enterprise. Надійні смартфони від таких компаній, як Zebra, Honeywell, Sonim та інших, включені в програму, і зараз навіть перевізники може продавати пристрої AER напряму компаніям за умови, що вони швидко затвердять випуски підтримки безпеки.

Процес надання пристрою в Android 10. Джерело: Джейсон Бейтон

The перелік вимог необхідний для входу в AER, не такий великий — набагато більше пристроїв Android могло б увійти до списку з огляду на низькі базові вимоги до апаратного забезпечення. Навіть вимоги до програмного забезпечення AER не потребують значних змін від постачальників, як зазначено в кількох внутрішніх документах Google. В одному з документів описано, як постачальники мають розробляти піктограми для програм у робочому профілі, додавати окрему вкладку для програм робочого профілю в панель запуску, окремі цілі спільного доступу для програм в особистому та робочому профілях, попереднє завантаження певних програм Google і керування даними між профілями спілкування. Інший документ описує вимоги до UX для вкладки запуску робочого профілю, швидкого налаштування робочого профілю плитка, діалогові вікна робочого профілю, освітні повідомлення панелі запуску, перемикання контексту та інший дизайн системи елементів. Ці вимоги спрямовані на просування мінімального стандарту прийнятного апаратного забезпечення, а також узгодженості UX програмного забезпечення між пристроями, рекомендованими Android Enterprise.

Однак, здається, вимога до пристроїв швидко отримувати оновлення безпеки кожного місяця Бюлетень безпеки Android (ASB) виявився занадто високим бар'єром для багатьох постачальників.

Google наполягає на прозорості оновлень для Android Enterprise Recommended

Розробник Android @deletescape, який нещодавно поділився злитою чернеткою Документ із визначенням сумісності Google для Android 11, отримав витік проекту нових рекомендованих вимог Android Enterprise для пристроїв під управлінням Android 11. Під "Безпека пристрою", який ми відтворюємо нижче, Google пропонує скасувати ряд вимог для програми AER. Згідно з цими новими запропонованими правилами, пристрої AER більше не будуть гарантовано отримувати оновлення виправлень безпеки протягом 90 днів після ASB. Цікаво, що один із рядків на діаграмі свідчить про те, що Google фактично посилив цю вимогу з 90 днів до 30 днів із переходом на Android 10, але Google досі не оновив публічний список вимог щоб відобразити цю зміну. Тим не менш, згідно із запропонованими змінами, ця вимога більше не застосовуватиметься до рекомендованих Android Enterprise пристроїв під керуванням Android 11. Крім того, від постачальників також більше не потрібно буде надавати три роки регулярних оновлень безпеки для пристроїв AER. Однак вони все одно повинні будуть надавати оновлення "Emergency Security Maintenance Release" (ESMR), що, імовірно, означає, що їм потрібно розгортати лише оновлення, що містять виправлення критичної безпеки уразливості.

Android 10 проти Android 11 – рекомендовані вимоги безпеки пристрою для Android Enterprise

Категорія	Серійний номер	ПОВИНЕН / МОЖЕ	Атрибут і реалізація	Коментарі
Q (Android 10)	R (Android 11)
Безпека пристрою	1	МОЖЕ	Керуйте програмою винагороди за вразливість OEM (VRP)	Керуйте програмою винагороди за вразливість OEM (VRP)
2	МОЖЕ	Підтримка StrongBox	Підтримка StrongBox
3	МОЖЕ	Підтримка Keystore з апаратною підтримкою	Підтримка Keystore з апаратною підтримкою
4	МОЖЕ	Підтримка атестації ідентифікатора пристрою	Підтримка атестації ідентифікатора пристрою
5	МОЖЕ	Підтримка атестації ключів	Підтримка атестації ключів
6	30-денні оновлення безпеки	Вимогу видалено	Замінено вимогою прозорості безпеки
7	ПОВИНЕН	3-річна підтримка випуску екстреного обслуговування безпеки (ESMR)	3-річна підтримка випуску екстреного обслуговування безпеки (ESMR)	Замінено вимогою прозорості безпеки
8	Шифрування на основі файлів – увімкнено за умовчанням. Використовує реалізацію AOSP.	Вимогу видалено	Це вимога GMS для всіх пристроїв
9	90-денні оновлення безпеки	Вимогу видалено	Замінено вимогою прозорості безпеки
10	3-річна підтримка оновлень системи безпеки (можливо після 3-го року ESMR)	Вимогу видалено	Замінено вимогою прозорості безпеки
11	Опублікуйте останній рівень виправлення безпеки	Вимогу видалено	Замінено вимогою прозорості безпеки

читати далі

Як зазначено в діаграмі, Google пропонує замінити багато цих вимог новими вимогами щодо «прозорості». Дійсно, Google пропонує додати новий розділ під назвою "Прозорість оновлень безпеки/ОС." У нових вимогах детально описано, як постачальники повинні будуть публікувати інформацію, таку як дата завершення терміну служби для оновлених версій безпеки, останнє виправлення безпеки що доступно, як часто пристрій отримуватиме оновлення, які виправлення містяться в кожному оновленні, доставку та заплановані оновлення програмного забезпечення пристрою тощо. Цікаво, що Google також вимагає, щоб пристрої Android 11 пройшли сертифікаційне тестування Альянс ioXt перш ніж вони зможуть стати рекомендованими для Android Enterprise. IoXt Alliance — це альянс компаній, метою яких є покращення безпеки продуктів IoT. Його членами є Amazon, Facebook, Google, NXP тощо. Google каже, що наявність цієї сертифікації додасть прозорості, мабуть, оскільки це дасть підприємств незалежний показник безпеки певного пристрою, а не лише Google запевнення.

Вимоги до прозорості оновлень безпеки/ОС (нові) для Android Enterprise рекомендовано

Категорія	Серійний номер	ПОВИНЕН / МОЖЕ	Атрибут і реалізація	Коментарі
Q (Android 10)	R (Android 11)
Прозорість оновлень безпеки/ОС	1	ПОВИНЕН	ОБОВ’ЯЗКОВО публікувати наступну інформацію про оновлення на веб-сайті OEM- Кінцева дата підтримки SMR (остання дата, коли пристрій отримає SMR)- Остання доступний патч безпеки- Частота оновлень, які пристрій отримуватиме- Виправлення, що містяться в патчі безпеки, включаючи будь-які специфічні для OEM виправлення	Зміна вимоги з підтримки SMR на прозорість SMR/патчів/оновлень
2	ПОВИНЕН	ПОВИНЕН опублікувати наступну інформацію про ОС на веб-сайті OEM- ОС, з якою постачається пристрій- Поточна основна версія ОС- Усі основні оновлення версій ОС, які отримає пристрій	Зміна вимоги з підтримки на прозорість, наприклад: Pixel 3 – Версія, що поставляється – Android 9 – Поточна версія – Android 10 – Очікувана основна версія – Android 11
3	ПОВИНЕН	Передайте пристрій на сертифікацію IoXT	Оцінка IoXT додає прозорості

читати далі

Ні для кого не секрет, що постачальники мають проблеми з розгортанням щомісячних оновлень безпеки. Є багато, багато причин, чому це так: затримки сертифікації оператора, очікування патчів від чіпсета та інші постачальників, труднощі із застосуванням патчів до сильно модифікованих збірок фреймворку Android і позадеревних ядер Linux, а також більше. Деякі користувачі Android навіть звернули увагу на те, як деякі постачальники не відповідають вимогам AER. Хоча зусилля Google щодо розробки та ліцензійні угоди мають допоміг покращитися Наскільки швидко з’являються оновлення безпеки для багатьох пристроїв, вони явно не змогли задовольнити поточні вимоги до виправлень безпеки для програми Android Enterprise Recommended. Послаблення цих вимог на користь більшої прозорості допоможе зробити програму більш доступною постачальникам, а також дають підприємствам більше впевненості в конкретному пристрої, який вони вибирають для свого робітників.

Запропоноване пом’якшення оновлень виправлень безпеки — це, звичайно, не єдина зміна, яка може відбутися в програмі Android Enterprise Recommended для Android 11. Google також планує збільшити мінімальні вимоги до апаратного забезпечення з 2 ГБ оперативної пам’яті до 3 ГБ оперативної пам’яті, посилити вимоги до навчання та запровадити новий набір вимог для робочого профілю UX. Проте більшість із цих змін не вплинуть на працівників інтелектуальної праці. Android на підприємстві значно виріс з перших днів. Якщо вам цікаво дізнатися більше про його історію, рекомендую прочитати ця чудова стаття від Джейсона Бейтона.