中堅企業の情報システム部門にとって、Keenaduバックドア問題は「個人のスマートフォンの問題」ではない。社員私物端末（BYOD）、現場用業務端末、受付タブレット、デジタルサイネージ、検品端末、KIOSK 端末まで、社内には想像以上の Android 端末が点在しており、その中に中国 OEM 製の感染リスク機種が紛れ込んでいる可能性は決して低くない。

本記事では、年商 50 億円から 500 億円規模、従業員 300 名から 3,000 名クラスの中堅企業の情報システム部門が、Keenadu バックドアに対して 一括で社内端末を点検し、感染機種を特定し、隔離・回収するまでの実務手順 を解説する。属人化を排し、限られた情シス人員でも 2 週間程度で完遂できる現実的な手順設計を意図した内容である。

なぜ「個別ユーザーまかせ」では破綻するのか

Keenadu の調査を行った Human Security の報告および JPCERT/CC、IPA の関連注意喚起を踏まえると、Keenadu はファームウェアレベルで仕込まれているため通常のセキュリティアプリでは検出できない。これはつまり、社員に「マカフィーやウイルスバスターでスキャンしてください」と依頼しても無意味であるということを意味する。

加えて、社員の自己申告に頼ると以下の問題が発生する。

失敗パターン発生理由
端末メーカーを答えられない中華系 OEM はブランド名と実メーカーが乖離しており、利用者が把握していないケースが多い
「Samsung です」と思い込んでいる実際はノーブランド端末で UI のテーマが類似しているだけ
BYOD 端末を申告したがらないプライバシー侵害を懸念して回答しない、または虚偽申告する
棚卸し対象外の業務端末が漏れる倉庫の在庫管理、受付、店舗 KIOSK 等が情シスの管理外
このため、情シス主導で物理的・技術的にチェックを進める標準手順 が必要となる。

全体フローの 4 ステップ

中堅企業向けに最適化した一括チェックの全体像は以下の通りである。

  1. 端末資産棚卸し（社内すべての Android 端末を 1 台残らずリストアップ）
  2. fingerprint 突合（Build.MANUFACTURER 等のシステム情報を一括収集して感染確認機種リストと照合）
  3. 物理確認（疑わしい端末を物理的に手元で確認）
  4. 隔離・回収・代替（感染確定機種をネットワークから切り離し、代替機を支給）

それぞれを情シス 2 名から 3 名で 2 週間以内に完遂できる手順に落とし込む。

ステップ 1 ｜端末資産棚卸し（所要 3 日）

棚卸し対象を定義する

「会社が支給した端末」だけでなく、以下の端末カテゴリすべてが対象となる。

カテゴリ想定例
業務支給スマートフォン営業、外勤、サポート部門の社用 Android
業務支給タブレット倉庫の検品、店舗 POS、医療現場の電子カルテ閲覧端末
BYOD 端末社員私物の Android（メール、Microsoft 365、Salesforce 等社内アクセスあり）
受付・サイネージ端末エントランスの来客タブレット、デジタルサイネージ用 Android TV box
工場・現場端末製造ラインの記録端末、ハンディターミナル代替の汎用 Android
試験・開発端末QA チームの動作確認用ストック、ベンダー貸与端末
特に見落とされがちなのは 受付タブレット と サイネージ用 Android TV box だ。これらは情シスではなく総務や店舗オペレーション部門が調達しており、安価な中華系 OEM が選ばれているケースが頻出する。

データソースを統合する

棚卸しに使えるデータソースは以下が代表的である。

  • 資産管理台帳（固定資産台帳、リース管理表）
  • MDM コンソール（Microsoft Intune、Jamf、Workspace ONE 等の登録済み端末リスト）
  • Active Directory / Entra ID の登録デバイス
  • DHCP リース履歴（過去 3 ヶ月分の Android 系 OUI を抽出）
  • 無線 LAN コントローラのクライアント履歴（SSID 別、フロア別）
  • 経費精算システムの「通信費・端末代」明細（BYOD 補助申請）

これらを CSV で抽出して、シリアル番号・MAC アドレス・IMEI・ホスト名・所有者・部門を統合した一枚の棚卸し台帳を作る。完璧を目指さず 「Android っぽい端末を抜け漏れなく拾うこと」 を優先するのが実務的である。

ステップ 2 ｜ fingerprint 突合（所要 4 日）

収集すべきシステム情報

Keenadu の感染確認機種を特定するには、Android の build.prop または adb 経由で以下の情報を取得する。

項目adb コマンド例用途
Build.MANUFACTURER`adb shell getprop ro.product.manufacturer`中華系 OEM 検出
Build.MODEL`adb shell getprop ro.product.model`感染機種一覧との突合
Build.FINGERPRINT`adb shell getprop ro.build.fingerprint`完全 ID 照合
Android セキュリティパッチ`adb shell getprop ro.build.version.security_patch`古い AOSP 版の検出
GMS / Play Protect 状態`adb shell pm list packages com.google.android.gms`Google 認証取得有無
インストール済み system 配下 apk`adb shell pm list packages -s`Keenadu 関連パッケージ名検出

MDM 経由で一括収集する

Microsoft Intune、Jamf Pro、VMware Workspace ONE などの MDM が導入されているならば、デバイスインベントリ機能で Manufacturer / Model / OS バージョンを CSV 出力できる。これと社内棚卸し台帳を突き合わせ、以下の条件にあてはまる端末を 要確認リスト に振り分ける。

  • Manufacturer が中華系 OEM（具体名は IPA・JPCERT/CC が随時更新する注意喚起を参照）
  • Model が Human Security 報告の感染確認機種一覧に含まれる
  • セキュリティパッチが 2 年以上未更新
  • Google Play Protect 認証なし（GMS 非搭載）
  • system 配下に未知の apk が存在する

MDM 未導入の場合の代替案

MDM 未導入の中堅企業も多い。その場合は以下のいずれかで対応する。

  • 無料の Google Endpoint Verification を Microsoft 365 / Google Workspace と連携して最低限のインベントリを取る
  • 社員に端末情報をフォームで自己申告させる（製造元・型番・Android バージョンの 3 項目に絞る）
  • 資産部門の購買履歴 から「過去 3 年で購入した Android 端末」のメーカーと型番リストを抽出

棚卸しと fingerprint 収集のいずれかを完璧にやろうとすると破綻する。「8 割の端末を捕捉できれば残り 2 割は物理確認に回す」と割り切るのが情シス実務のコツである。

ステップ 3 ｜物理確認（所要 4 日）

物理確認の対象

ステップ 2 で fingerprint が取れなかった端末、および要確認リストに振り分けられた端末は、以下のいずれかで物理確認する。

  • 社員に総務窓口への持ち込みを依頼
  • 情シス担当が現場（倉庫、店舗、工場）を巡回
  • リモート支店の場合は端末の写真とシリアル銘板の撮影を依頼

物理確認時のチェック項目

物理的に手元に来た端末については、以下の手順で 1 台あたり 5 分から 10 分程度で確認する。

  1. 設定 → 端末情報を開き、「製造元」「機種名」「Android バージョン」「ビルド番号」を控える
  2. Google Play Store を起動し、「この端末は Play Protect 認定済みです」表示の有無を確認
  3. 設定 → アプリ → システムアプリを表示にチェックを入れ、見慣れないパッケージがないか確認（パッケージ名に `com.adups`、`com.android.adsystemservice` 等の不審な広告 SDK が混入していないか）
  4. 設定 → ネットワーク → モバイルデータ通信量で、バックグラウンド通信が異常に多いアプリがないか確認

これらを チェックリスト として印刷配布し、情シス担当が機械的に処理できる状態にする。

ステップ 4 ｜隔離・回収・代替（所要 3 日）

感染確定時の即時対応

Keenadu 感染が確定した端末は、以下を即時実施する。

  1. 社内ネットワークから切り離す（MDM の Selective Wipe、Wi-Fi プロファイル削除、VPN プロファイル無効化）
  2. 業務アカウントの強制サインアウト（Microsoft 365、Google Workspace、Salesforce、SAP 等の該当ユーザーセッション全削除）
  3. 業務アカウントのパスワードリセット強制（端末からセッショントークンが漏洩している前提で対応）
  4. MFA 再登録（旧端末に紐づいた認証アプリ・SMS の無効化、新規登録）
  5. 端末を物理回収または初期化（社員に廃棄させず、情シスが回収して証跡として保管。フォレンジック調査の必要性に備える）

代替機の支給ポリシー

Keenadu のような事案を二度と起こさないためには、調達ポリシーの改訂が必須である。具体的には以下の基準を社内規程に明記する。

  • 業務利用 Android は Google Play Protect 認証取得デバイスに限定
  • 2 年以上のセキュリティパッチ提供がメーカーから保証されていること
  • 中華系 OEM の調達は情シス事前承認制（理由書・代替検討の証跡を残す）
  • 受付・サイネージ用途は国産または Google 認証取得済みの Android TV box のみ

調達ポリシーの整備までセットで進めることで、社内の現場担当が善意で安価な OEM を購入してしまうルートを塞げる。

チェックの進捗を可視化するダッシュボード設計

中堅企業情シスの実務では、経営層・監査委員会への中間報告が必須となる。以下の 4 指標をダッシュボードに表示すると進捗管理が容易になる。

指標計測方法目標
棚卸し対象端末数統合台帳の Android 行数2 週間以内に確定
fingerprint 取得率MDM またはフォームで OS バージョンが取れた端末数 / 対象端末数80% 以上
要確認リスト消化率物理確認完了 / 要確認リスト100%（漏れゼロが原則）
感染確定端末の隔離完了率隔離完了端末 / 感染確定端末100%（24 時間以内）
経営層が知りたいのは「どれだけ進んでいるか」であり、専門用語ではなく 進捗率と完了予定日 を出すことが情シス側の信頼を担保する。

関連記事

参考資料・出典

  • 独立行政法人情報処理推進機構（IPA）「サプライチェーンに関する注意喚起」
  • JPCERT コーディネーションセンター「Android 端末のサプライチェーンリスク」
  • 警察庁サイバー警察局 公開資料
  • 個人情報保護委員会 ガイドライン
  • Google Android Security ドキュメント（Play Protect、CDD）
  • Human Security 公開レポート

サプライチェーン攻撃対策のご相談

Keenadu のような事案は、社内に潜む「想定外の調達ルート」を炙り出す機会でもあります。GXO 株式会社では、中堅企業の情報システム部門向けに、Android 端末の一括棚卸し支援、MDM 導入・運用設計、調達ポリシー改訂のテンプレート提供、サプライチェーン攻撃対策のヒアリングを無料でご提供しています。社内の点検手順や代替機選定にお悩みの場合は、お気軽にご相談ください。