独占: Google は Android Enterprise Recommendation のセキュリティ アップデートを緩和する予定です

のデータによると、Android は全体的に支配的なスマートフォン オペレーティング システムですが、 IDC, Apple の iOS は、ほとんどの企業が選択する OS です。 その理由は簡単にわかります。Apple は一般に、ほとんどの Android デバイス メーカーよりもはるかに長く、より一貫して iOS デバイスを更新します。 スマートフォンを更新し、iPhone は設定と管理が簡単で、企業が選択した場合にサポートする SKU がはるかに少なくなります。 りんご。 ただし、コストの削減やハードウェアの柔軟性の向上など、企業が Android デバイスを選択する理由もあります。 Android を職場にとってさらに魅力的なものにするために、Google は 2015 年初めに「Android for Work」を立ち上げました (後に「Android Enterprise」にブランド変更されました) 2016年末に). そして 2018 年の初めに、Google は Android エンタープライズ推奨 (AER) プログラム ビジネス用途のデバイスを認定します。 Google は、最小ハードウェア仕様、一括導入のサポート、 ロック解除されたデバイスの可用性、管理されたプロファイルで実行されるアプリの動作の一貫性、リリースから 90 日以内の Android セキュリティ アップデートの配信 (少なくとも 3 回) 年。

しかし、Android開発者@によって文書が発見されました。削除スケープ によってレビューされました XDA-開発者 Google が Android エンタープライズ推奨デバイスのセキュリティ アップデート要件を緩和する予定であることを明らかにしました。 その代わり、Googleはベンダーに対し、セキュリティアップデートの扱い方について透明性を高めるよう求めている。 @deletescape によると、これらの文書は過去 15 日以内にベンダーと共有されました。 したがって、Android Enterprise Recommendation に対するこれらの提案された変更が実現するかどうかは保証できませんが、 要件の最終リストに組み込まれたことで、Google がごく最近これらを検討したことが少なくとも確認できます。 変化します。

現在、 170 種類の Android デバイス それは Android Enterprise 推奨です。 HMD グローバル、ソニー、モトローラ, オッポ、 そしてもちろん、 グーグル、AER であるデバイスを提供します。 ワンプラスでも は、自社のデバイスをプログラムに基づいて認定することを検討しています。 ただし、Android エンタープライズ推奨デバイスを販売している企業は、有名な消費者向けスマートフォン ブランドだけではありません。 頑丈なスマートフォン Zebra、Honeywell、Sonim などの企業の製品がプログラムに含まれており、現在 運送業者でも 企業がセキュリティ メンテナンス リリースを迅速に承認する場合、AER デバイスを企業に直接販売できます。

Android 10 のデバイス プロビジョニング フロー。 ソース： ジェイソン・ベイトン

の 要件のリスト AER への参加に必要な要件はそれほど広範囲ではありません。基本的なハードウェア要件が低いことを考慮すると、さらに多くの Android デバイスがリストに含まれる可能性があります。 いくつかの Google 社内文書で概要が説明されているように、AER のソフトウェア要件でも、ベンダーによる多くの変更は必要ありません。 ドキュメントの 1 つは、ベンダーが仕事用プロファイルのアプリのアイコン バッジをデザインし、仕事用プロファイル アプリの専用タブを追加する方法を概説しています。 ランチャー、個人用プロファイルと仕事用プロファイルのアプリの個別の共有ターゲット、特定の Google アプリケーションのプリロード、プロファイル間データの管理 コミュニケーション。 別のドキュメントでは、仕事用プロファイルの起動タブ、仕事用プロファイルのクイック設定の UX 要件の概要を説明しています。 タイル、仕事用プロファイルダイアログ、ランチャー教育メッセージ、コンテキスト切り替え、その他のシステム設計 要素。 これらの要件は、Android エンタープライズ推奨デバイス間で許容可能なハードウェアとソフトウェアの UX の一貫性の最低限の標準を促進することを目的としています。

ただし、毎月の更新後にセキュリティ パッチの更新を迅速に取得することがデバイスの要件であるようです。 Android セキュリティ情報 (ASB) 多くのベンダーにとって障壁が高すぎることが判明しています。

Google、Android Enterprise 推奨のアップデートの透明性を推進

Android開発者@削除スケープ、最近リークされた草稿を共有しました Google の Android 11 互換性定義ドキュメント、Android 11 を実行するデバイスの新しい Android Enterprise Recommendation 要件のリークされたドラフトを入手しました。 下 "デバイスのセキュリティ以下に再掲したセクションを参照すると、Google は AER プログラムの多くの要件を削除することを提案しています。 これらの新たに提案されたルールの下では、AER デバイスは ASB から 90 日以内にセキュリティ パッチの更新を受信することが保証されなくなります。 興味深いことに、グラフ内の行の 1 つは、Google が Android 10 への移行に伴いこの要件を実際に 90 日から 30 日に厳格化したが、Google はまだこの要件を更新していないことを示唆しています。 要件の公開リスト この変更を反映するために。 ただし、提案された変更では、この要件は Android 11 を実行する Android Enterprise Recommendation デバイスには適用されなくなります。 さらに、ベンダーは AER デバイスに対して 3 年間の定期的なセキュリティ更新プログラムを提供する必要もなくなります。 ただし、「緊急セキュリティ メンテナンス リリース」(ESMR) アップデートを提供する必要はあります。 これはおそらく、重要なセキュリティの修正を含むアップデートをロールアウトするだけでよいことを意味します。 脆弱性。

Android 10 と Android 11 - Android Enterprise 推奨のデバイス セキュリティ要件

カテゴリー	シリアルナンバー	必須/5月	属性と実装	コメント
Q（Android10）	R（アンドロイド11）
デバイスのセキュリティ	1	5月	OEM 脆弱性報奨金プログラム (VRP) を運営する	OEM 脆弱性報奨金プログラム (VRP) を運営する
2	5月	StrongBox のサポート	StrongBox のサポート
3	5月	ハードウェアによるキーストアのサポート	ハードウェアによるキーストアのサポート
4	5月	デバイス ID 構成証明のサポート	デバイス ID 構成証明のサポート
5	5月	鍵証明書のサポート	鍵証明書のサポート
6	30日間のセキュリティアップデート	要件が削除されました	セキュリティの透明性要件に置き換えられました
7	しなければならない	緊急セキュリティ メンテナンス リリース (ESMR) の 3 年間のサポート	緊急セキュリティ メンテナンス リリース (ESMR) の 3 年間のサポート	セキュリティの透明性要件に置き換えられました
8	ファイルベースの暗号化 - デフォルトでオン。 AOSP実装を使用します。	要件が削除されました	これはすべてのデバイスに適用される GMS 要件です
9	90日間のセキュリティアップデート	要件が削除されました	セキュリティの透明性要件に置き換えられました
10	3 年間のセキュリティ アップデート サポート (3 年目の ESMR が延長される場合があります)	要件が削除されました	セキュリティの透明性要件に置き換えられました
11	最新のセキュリティパッチレベルを公開する	要件が削除されました	セキュリティの透明性要件に置き換えられました

続きを読む

表で述べたように、Google はこれらの要件の多くを新しい「透明性」要件に置き換えることを提案しています。 実際、Google は「」というタイトルの新しいセクションの追加を提案しています。セキュリティ/OS アップデートの透明性新しい要件では、セキュリティ メンテナンス リリースのサポート終了日や最新のセキュリティ パッチなどの情報をベンダーがどのように公開する必要があるかが詳しく規定されています。 利用可能なもの、デバイスがアップデートを受け取る頻度、各アップデートに含まれる修正、デバイスの出荷および計画されているソフトウェア アップデートなど。 興味深いことに、Google は、Android 11 デバイスが認証テストを受けることも要求しています。 ioXtアライアンス Android Enterprise Recommendation になる前に。 ioXt Alliance は、IoT 製品のセキュリティを向上させることを目的とした企業のアライアンスです。 メンバーには、Amazon、Facebook、Google、NXP などが含まれます。 Google は、この認定を取得すると透明性が高まると述べています。 企業向けに、Google だけではなく、特定のデバイスの安全性を示す独立した指標 保証。

Android Enterprise 推奨のセキュリティ/OS アップデートの透明性 (新規) 要件

カテゴリー	シリアルナンバー	必須/5月	属性と実装	コメント
Q（Android10）	R（アンドロイド11）
セキュリティ/OS アップデートの透明性	1	しなければならない	次の更新情報を OEM Web サイトで公開する必要があります - SMR サポート終了日 (デバイスが SMR を受信する最終日) - 最新 利用可能なセキュリティ パッチ - デバイスが受信するアップデートの頻度 - セキュリティ パッチに含まれる修正（OEM 固有の修正を含む） 修正	SMR サポートから SMR/パッチ/アップデートの透明性への要件の変更
2	しなければならない	次の OS 情報を OEM Web サイトで公開する必要があります - デバイスに同梱されている OS - 現在のメジャー OS バージョン - デバイスが受け取るすべてのメジャー OS バージョン アップデート	要件をサポートから透明性へ変更する例: Pixel 3- 出荷されたバージョン - Android 9- 現在​​のバージョン - Android 10- 予想されるメジャー バージョン - Android 11
3	しなければならない	デバイスを IoXT 認証に提出する	IoXT スコアリングにより透明性が向上

続きを読む

ベンダーが毎月のセキュリティ パッチ更新の展開に対応するのに苦労していることは周知の事実です。 その理由は数多くあります。通信事業者の認証の遅れ、チップセットからのパッチの待機などです。 ベンダー、大幅に変更された Android フレームワーク ビルドやツリー外の Linux カーネルにパッチを適用することの難しさ、および もっと。 一部の Android ユーザーは、一部のベンダーのやり方に注目しています。 AER要件を満たしていない. Google の開発努力とライセンス契約は、 改善に役立ちました 多くのデバイスでセキュリティ アップデートがどれほど迅速に展開されるかを考えても、Android Enterprise Recommendation プログラムの現在のセキュリティ パッチ要件を維持できていないことは明らかです。 より透明性を高めるためにこれらの要件を緩和することは、両方ともプログラムをよりアクセスしやすくするのに役立ちます ベンダーに提供するだけでなく、企業が自社用に選択した特定のデバイスに対する信頼性を高めることもできます。 労働者。

もちろん、Android 11 向けの Android Enterprise Recommendation プログラムに加えられる可能性のある変更は、提案されているセキュリティ パッチ アップデートの緩和だけではありません。 Google はまた、ハードウェアの最小要件を 2 GB の RAM から 3 GB の RAM に増やし、トレーニング要件を厳格化し、仕事用プロファイル UX の新しい要件セットを実装する予定です。 ただし、これらの変更のほとんどはナレッジ ワーカーには影響しません。 企業における Android は、初期の頃から大きく成長してきました。 その歴史について詳しく知りたい場合は、一読をお勧めします ジェイソン・ベイトンによるこの素晴らしい記事.