Keenadu バックドア事案を契機に、中堅企業情シスから「MDM で中国 OEM 製 Android 端末を自動検知できないか」という相談が急増している。MDM コンプライアンスポリシーで Manufacturer や Build prop、証明書チェーンを検査することで、人手の棚卸しに頼らずに 新規登録段階・既存端末の双方 で疑わしい端末を自動的に振り分けることが可能だ。
本記事では、Microsoft Intune、Jamf Pro、VMware Workspace ONE の 3 大 MDM プラットフォームについて、中国 OEM 製 Android 端末を検知するための具体的なポリシー設定例を解説する。BYOD 環境でも適用できる現実的な設計方針を含めている。
検知ルールの設計方針
技術的には、Android 端末から取得できる以下の項目を組み合わせて判定する。
| 項目 | 取得経路 | 判定の意味 |
|---|---|---|
| `Build.MANUFACTURER` | Android API、MDM の Device Inventory | OEM メーカー名 |
| `Build.BRAND` | 同上 | 流通ブランド名 |
| `Build.FINGERPRINT` | 同上 | ビルド固有 ID（メーカー＋機種＋バージョンの一意 ID） |
| Google Play Protect 認定状態 | Google API、SafetyNet/Play Integrity | Google が認証したデバイスかどうか |
| Android セキュリティパッチレベル | Build.VERSION.SECURITY_PATCH | 最新パッチ適用状態 |
| 証明書チェーン（端末ルート CA） | Key Attestation、Hardware-backed Keystore | ハードウェアの真正性 |
| インストール済 system 配下パッケージ | `pm list packages -s` | 不審な system app 検出 |
- 隔離（社内リソースへのアクセス遮断）
- 通知（情シスにアラート、ユーザーに警告メッセージ）
- アクセス制限（特定アプリ・特定ネットワークのみ許可）
Microsoft Intune での実装
前提条件
Microsoft Intune で Android Enterprise（仕事用プロファイル / 完全管理）を有効化しており、Android デバイスが登録済みであること。Microsoft Entra ID（旧 Azure AD）の条件付きアクセスと連携できることを前提とする。
コンプライアンスポリシーの設定
Intune 管理センター → デバイス → コンプライアンスポリシー → 新規作成で、Android Enterprise を選択し、以下を設定する。
| 設定項目 | 推奨値 | 理由 |
|---|---|---|
| Google Play Protect の SafetyNet デバイス構成証明 | 「基本的な整合性とデバイス認証済み」 | 認証取得デバイスのみ通過 |
| 脅威スキャン | 「必要」 | Play Protect 有効化を強制 |
| 最小 OS バージョン | Android 11 以上 | 古い AOSP を除外 |
| 最大 OS バージョン | （任意で上限設定） | β版を業務利用させない |
| 最小セキュリティパッチレベル | 直近 12 ヶ月以内の日付 | パッチ未適用デバイスの除外 |
カスタムポリシーで Manufacturer を判定する
Intune 標準ポリシーでは Manufacturer を直接判定できない。そこで Microsoft Graph API または Intune の デバイスフィルター（動的） を使用し、以下のような条件で動的グループを作成する。
このグループに対して条件付きアクセスポリシーを適用し、Microsoft 365、SharePoint、Teams などへのアクセスをブロックする。
Compliance Action の設計
非準拠端末に対して以下のアクションを段階的に発動する。
- Day 0: 非準拠通知メールをユーザーに送信、修復手順を案内
- Day 3: 社用メール・SharePoint へのアクセス遮断
- Day 7: Selective Wipe（業務データのみ削除、私物データは保持）
中堅企業の情シスは「いきなり全部止めるとクレームの嵐」を経験的に知っているので、段階エスカレーションが運用上の鉄則となる。
Jamf Pro での実装
前提条件
Jamf Pro が Android Enterprise の管理ソリューションとして稼働していること（Jamf Pro 自体は iOS / macOS が主軸だが、近年 Android Enterprise 対応を強化している）。多くの中堅企業では Jamf を Mac / iPhone 用、Intune を Windows / Android 用に併用しているケースが多い。
Smart Group の作成
Jamf Pro → Devices → Smart Device Groups → New で、以下の条件で Smart Group を作成する。
| 条件 | 演算子 | 値 |
|---|---|---|
| Make | is | （要注意 OEM 名のリスト） |
| Model | is | （感染確認機種型番群） |
| OS Version | less than | 11.0 |
| Last Inventory Update | less than X days ago | 7 |
Configuration Profile によるアクセス制限
該当 Smart Group に対して、以下の Configuration Profile を適用する。
- VPN プロファイルの剥奪
- Wi-Fi（社内 SSID）プロファイルの削除
- 業務アプリ（Microsoft Outlook、Salesforce Mobile など）のアンインストール
- Google Workspace（旧 G Suite）アカウントの強制サインアウト
Jamf Protect との連携
Jamf Protect を併用している場合、Threat Detection で system アプリの異常な挙動を検知できる。Keenadu のようにバックグラウンドで C2 通信を行うマルウェアは、ネットワークトラフィックに不審なパターンを残すため、ふるまい検知で補完的に検出可能だ。
VMware Workspace ONE での実装
前提条件
Workspace ONE UEM が稼働しており、Android 端末が Enrolled 状態であること。Workspace ONE Intelligence と連携することで、より高度な分析・自動化が可能になる。
Smart Group と Compliance Policy の組み合わせ
Workspace ONE UEM コンソール → Devices → Profiles & Resources → Compliance Policies で、以下の条件式を作成する。
| Rule | Condition |
|---|---|
| Device Manufacturer | Equals（要注意 OEM 名のリスト） |
| Device Model | Equals（感染確認機種型番群） |
| OS Version | Less Than 11.0 |
| Security Patch Level | Older Than 365 Days |
| Play Protect Status | Not Certified |
Workspace ONE Intelligence ダッシュボード
Workspace ONE Intelligence では、社内全 Android 端末の Manufacturer / Model 分布を可視化できる。Keenadu のような事案発生時に、影響を受ける端末数と部門別分布を即座に把握できるため、初動対応の判断材料として有効だ。
BYOD 環境での運用上の注意
中堅企業の多くは、業務支給端末と BYOD（社員私物）端末が混在している。BYOD で MDM フル管理を強制するとプライバシー懸念で社員から反発を受けるため、以下のいずれかの戦術を取る。
戦術 A: 仕事用プロファイル（Work Profile）限定の検知
Android Enterprise の Work Profile を使えば、私物部分には触れず、業務プロファイル内のみを管理できる。Manufacturer や Model の取得は端末全体で可能なため、「BYOD でも端末メーカーの判定だけはできる」 という関係性になる。これだけでも中華 OEM 検知としては十分機能する。
戦術 B: MAM（モバイルアプリケーション管理）アプローチ
MDM ではなく MAM（Microsoft Intune App Protection Policy 等）で、業務アプリ単位で「許可されたデバイスからのみ起動可能」とする。アプリ起動時に SafetyNet / Play Integrity API で端末認証を行い、未認定デバイスからは業務アプリ自体が起動しない設計にできる。
戦術 C: 社内通達と並行運用
「業務アクセスを許可する端末は Google Play Protect 認定済みに限る」という社内ルールを明文化した上で、MDM での技術的検知と組み合わせる。BYOD 補助金（社員に通信費補助を出す制度）の受給条件として「認定済み端末を業務利用すること」を明記すると、社員の自発的な機種選定を促せる。
ポリシー作成時の落とし穴
落とし穴 1: ホワイトリスト vs ブラックリスト
「中華 OEM をブラックリスト指定する」アプローチは、新規 OEM が次々と登場するため運用が破綻しやすい。逆に「Google Play Protect 認定済みデバイスのみホワイトリスト許可」のほうが運用負荷が低い。中堅企業情シスの人員リソースを考えると、ホワイトリスト方式が現実解 である。
落とし穴 2: 古い社内端末の救済
検知ルールを厳しくすると、ローコストで導入していた既存端末（特に倉庫・現場・店舗の業務端末）が一斉に非準拠になることがある。代替機への切り替え予算と移行スケジュールを 同時並行で経営層に承認取得 しないと、業務が止まる事態に陥る。
落とし穴 3: Play Integrity API の偽装
技術的には Play Integrity API のレスポンスを偽装する手法も存在する（root 化端末で Magisk + Play Integrity Fix 等）。ただし MDM コンソール側で hardware-backed key attestation を要求すれば、ハードウェアレベルでの偽装はほぼ不可能となる。中堅企業の業務利用範囲では十分な精度を確保できる。
GXO実務追記: システム開発・DX投資で発注前に確認すべきこと
この記事のテーマは、単なるトレンド紹介ではなく、要件定義、費用、開発体制、ベンダー選定、保守運用を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。
まず決めるべき3つの論点
| 論点 | 確認する内容 | 未整理のまま進めた場合のリスク |
|---|---|---|
| 目的 | 売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか | 成果指標が曖昧になり、PoCや開発が終わっても投資判断できない |
| 範囲 | 対象部署、対象業務、対象データ、対象システムをどこまで含めるか | 見積もりが膨らむ、または重要な連携が後から漏れる |
| 体制 | 自社責任者、現場担当、ベンダー、保守運用者をどう置くか | 要件確認が遅れ、納期遅延や品質低下につながる |
費用・期間・体制の目安
| フェーズ | 期間目安 | 主な成果物 | GXOが見るポイント |
|---|---|---|---|
| 事前診断 | 1〜2週間 | 課題整理、現行確認、投資判断メモ | 目的と範囲が商談前に整理されているか |
| 要件定義 / 設計 | 3〜6週間 | 要件一覧、RFP、概算見積、ロードマップ | 見積比較できる粒度になっているか |
| PoC / MVP | 1〜3ヶ月 | 検証環境、効果測定、リスク評価 | 本番化判断に必要な数値が取れるか |
| 本番導入 | 3〜6ヶ月 | 本番環境、運用設計、教育、改善計画 | 導入後の運用責任と改善サイクルがあるか |
発注前チェックリスト
- [ ] 発注前に目的、対象業務、利用者、現行課題を1枚に整理したか
- [ ] 必須要件、将来要件、今回はやらない要件を分けたか
- [ ] 見積比較で、開発費だけでなく保守費、運用費、追加改修費を見たか
- [ ] ベンダー選定で、体制、実績、品質管理、セキュリティ、引継ぎ条件を確認したか
- [ ] 検収条件を機能、性能、セキュリティ、ドキュメントで定義したか
- [ ] リリース後3ヶ月の改善運用と責任分界を決めたか
参考にすべき一次情報・公的情報
上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。
GXOに相談するタイミング
次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。
- 見積もり依頼前に、要件やRFPの粒度を整えたい
- 既存ベンダーの提案が妥当か第三者視点で確認したい
- 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
- 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
- PoCや診断で終わらせず、本番導入と運用改善まで進めたい
MDM中国製Android検知ルール｜Intune・Jamf・Workspace ONE設定2026を自社条件で診断したい方へ
GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。
※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。
関連記事
参考資料・出典
- Microsoft Learn「Intune を使用した Android デバイスのコンプライアンス ポリシー」
- Jamf 公式ドキュメント「Android Enterprise Management」
- VMware Docs「Workspace ONE UEM Compliance Policies」
- Google Android Developers「Play Integrity API」
- Google「Android Enterprise Recommended」プログラム
- 独立行政法人情報処理推進機構（IPA）モバイル端末ガイドライン
- JPCERT コーディネーションセンター「モバイル端末のセキュリティ管理」
サプライチェーン攻撃対策のご相談
MDM の導入・コンプライアンスポリシー設計は、中堅企業情シスにとって工数の重い作業です。GXO 株式会社では、Microsoft Intune、Jamf Pro、Workspace ONE のいずれの環境でも、中国 OEM 検知ポリシーのテンプレート提供、BYOD 運用設計、サプライチェーン攻撃を踏まえた多層防御のヒアリングを無料でご提供しています。MDM ポリシーの実装にお困りの場合は、お気軽にご相談ください。