中堅企業の情報システム部門にとって、Keenaduバックドア問題は「個人のスマートフォンの問題」ではない。社員私物端末(BYOD)、現場用業務端末、受付タブレット、デジタルサイネージ、検品端末、KIOSK 端末まで、社内には想像以上の Android 端末が点在しており、その中に中国 OEM 製の感染リスク機種が紛れ込んでいる可能性は決して低くない。
本記事では、年商 50 億円から 500 億円規模、従業員 300 名から 3,000 名クラスの中堅企業の情報システム部門が、Keenadu バックドアに対して 一括で社内端末を点検し、感染機種を特定し、隔離・回収するまでの実務手順 を解説する。属人化を排し、限られた情シス人員でも 2 週間程度で完遂できる現実的な手順設計を意図した内容である。
なぜ「個別ユーザーまかせ」では破綻するのか
Keenadu の調査を行った Human Security の報告および JPCERT/CC、IPA の関連注意喚起を踏まえると、Keenadu はファームウェアレベルで仕込まれているため通常のセキュリティアプリでは検出できない。これはつまり、社員に「マカフィーやウイルスバスターでスキャンしてください」と依頼しても無意味であるということを意味する。
加えて、社員の自己申告に頼ると以下の問題が発生する。
横にスクロールして確認できます
| 失敗パターン | 発生理由 |
|---|---|
| 端末メーカーを答えられない | 中華系 OEM はブランド名と実メーカーが乖離しており、利用者が把握していないケースが多い |
| 「Samsung です」と思い込んでいる | 実際はノーブランド端末で UI のテーマが類似しているだけ |
| BYOD 端末を申告したがらない | プライバシー侵害を懸念して回答しない、または虚偽申告する |
| 棚卸し対象外の業務端末が漏れる | 倉庫の在庫管理、受付、店舗 KIOSK 等が情シスの管理外 |
このため、情シス主導で物理的・技術的にチェックを進める標準手順 が必要となる。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか?
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
全体フローの 4 ステップ
中堅企業向けに最適化した一括チェックの全体像は以下の通りである。
- 端末資産棚卸し(社内すべての Android 端末を 1 台残らずリストアップ)
- fingerprint 突合(Build.MANUFACTURER 等のシステム情報を一括収集して感染確認機種リストと照合)
- 物理確認(疑わしい端末を物理的に手元で確認)
- 隔離・回収・代替(感染確定機種をネットワークから切り離し、代替機を支給)
それぞれを情シス 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 分程度で確認する。
- 設定 → 端末情報を開き、「製造元」「機種名」「Android バージョン」「ビルド番号」を控える
- Google Play Store を起動し、「この端末は Play Protect 認定済みです」表示の有無を確認
- 設定 → アプリ → システムアプリを表示にチェックを入れ、見慣れないパッケージがないか確認(パッケージ名に
com.adups、com.android.adsystemservice等の不審な広告 SDK が混入していないか) - 設定 → ネットワーク → モバイルデータ通信量で、バックグラウンド通信が異常に多いアプリがないか確認
これらを チェックリスト として印刷配布し、情シス担当が機械的に処理できる状態にする。
ステップ 4 |隔離・回収・代替(所要 3 日)
感染確定時の即時対応
Keenadu 感染が確定した端末は、以下を即時実施する。
- 社内ネットワークから切り離す(MDM の Selective Wipe、Wi-Fi プロファイル削除、VPN プロファイル無効化)
- 業務アカウントの強制サインアウト(Microsoft 365、Google Workspace、Salesforce、SAP 等の該当ユーザーセッション全削除)
- 業務アカウントのパスワードリセット強制(端末からセッショントークンが漏洩している前提で対応)
- MFA 再登録(旧端末に紐づいた認証アプリ・SMS の無効化、新規登録)
- 端末を物理回収または初期化(社員に廃棄させず、情シスが回収して証跡として保管。フォレンジック調査の必要性に備える)
代替機の支給ポリシー
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 導入・運用設計、調達ポリシー改訂のテンプレート提供、サプライチェーン攻撃対策のヒアリングを無料でご提供しています。社内の点検手順や代替機選定にお悩みの場合は、お気軽にご相談ください。
実務判断のポイント
この記事は、経営者、DX責任者、情シス、業務責任者向けです。現状棚卸し、業務改善、AI/DXロードマップ、実装優先順位を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。Keenadu企業一括チェック手順|情シス向け端末棚卸し実務ガイド2026に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの見解
DXは流行ツールの導入ではなく、現場業務、データ、権限、KPI、投資判断をつなぐ実装計画である。
GXOは最初から大規模刷新するより、棚卸し、優先順位付け、小さな実装、効果測定を繰り返すべきだと見る。
GXOは、DX成熟度診断、業務棚卸し、ロードマップ、AI/システム実装まで支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、DX診断、要件定義、システム開発、AI活用支援へ接続。さらに、短期診断から段階実装に進め、継続支援へ展開。
実行までの進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
FAQ
まず何から確認すべきですか?
最初に確認すべきなのは、対象業務、対象データ、責任者、判断期限です。情報収集だけで終えると、導入可否や対応優先順位を決められません。
社内だけで進めるべきですか?
既存業務の棚卸しは社内で進められます。ただし、要件定義、セキュリティ、費用対効果、ベンダー比較が絡む場合は、外部視点を入れた方が手戻りを抑えやすくなります。
GXOにはどの段階で相談できますか?
構想段階、予算化前、RFP作成前、既存システムの見直し段階から相談できます。現状棚卸し、業務改善、AI/DXロードマップ、実装優先順位の相談を入口に、実装や運用改善まで整理できます。
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。






