Keenadu 事案では、納品時に簡単な検証をしていれば検出できた事例が多数あった。 ファクトリーリセット後の system app 一覧比較、初回起動 30 分の通信ログ、ADB シェルでのビルド指紋確認――どれも 1 端末あたり 30-60 分で実施可能。本記事は中堅企業の情シスが内製で実施可能な 24 項目チェックリストを提示する。
目次
- 事前検証の必要性と適用範囲
- Sandbox 環境の最小構成
- チェックリスト 24 項目 全体像
- ① ADB／システム情報検査（6 項目）
- ② 通信ログ／パケットキャプチャ（5 項目）
- ③ APK／system app 解析（6 項目）
- ④ SafetyNet／Play Integrity（4 項目）
- ⑤ ファームウェア／Bootloader（3 項目）
- 検出時の判定フロー
- 運用工数と頻度
- よくある質問（FAQ）
事前検証の必要性と適用範囲
| 端末カテゴリ | 検証必須度 |
|---|---|
| 業務貸与スマホ／タブレット | 全数検証 |
| BYOD 申請端末 | 抜取検証＋登録時自動検査 |
| 専用業務端末（POS／検品） | 全数検証＋出荷時封緘確認 |
| 来客／案内端末 | 全数検証 |
| ロビー／会議室共有端末 | 全数検証 |
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
Sandbox 環境の最小構成
| 機材 | 用途 | 概算費用 |
|---|---|---|
| 隔離 LAN（VLAN） | 通信解析 | 既存ネットワーク機器流用 |
| 解析 PC（Linux） | ADB／APK 解析 | 既存 PC 流用 |
| パケットキャプチャ機（Raspberry Pi 等） | 通信記録 | 1-2 万円 |
| Wi-Fi AP（解析用） | 端末接続 | 1-2 万円 |
総予算 5 万円以内 で構築可能。
チェックリスト 24 項目 全体像
[① ADB／システム情報] 6 項目
[② 通信ログ／パケットキャプチャ] 5 項目
[③ APK／system app 解析] 6 項目
[④ SafetyNet／Play Integrity] 4 項目
[⑤ ファームウェア／Bootloader] 3 項目
合計 24 項目
① ADB／システム情報検査（6 項目）
# 1. ビルド指紋確認
adb shell getprop ro.build.fingerprint
# 2. ベンダ／ブランド確認
adb shell getprop ro.product.brand
adb shell getprop ro.product.manufacturer
# 3. Bootloader 状態
adb shell getprop ro.boot.flash.locked
# 4. SELinux 状態
adb shell getenforce
# 5. システムプロパティ全ダンプ
adb shell getprop > device_properties.txt
# 6. インストール済アプリ列挙
adb shell pm list packages -s -f > system_packages.txt
純正と異なる出力が出た場合は判定フロー（後述）へ。
② 通信ログ／パケットキャプチャ（5 項目）
1. 端末を解析 LAN（インターネット可）に接続
2. 30 分間 idle 放置（操作しない）
3. パケットキャプチャ（pcap 形式）取得
4. DNS クエリ一覧から不審ドメインを抽出
5. HTTPS SNI から接続先一覧を抽出
不審ドメイン判定基準：
- ホスティング国が OEM 公式 SDK／GMS と異なる
- 短い lifetime のドメイン（DGA 疑い）
- IP 直打ち
- 既知の C2 IOC ヒット
③ APK／system app 解析（6 項目）
# 1. system app 全 pull
adb shell pm list packages -s | while read line; do
pkg=$(echo $line | sed 's/package://')
apk_path=$(adb shell pm path $pkg | sed 's/package://')
adb pull $apk_path /tmp/apks/${pkg}.apk
done
# 2-6. 解析項目
- aapt dump で AndroidManifest 確認
- jadx でデコンパイル → 主要 Java ファイル目視
- 危険 permission 列挙（INTERNET / READ_PHONE_STATE / ACCESS_FINE_LOCATION）
- 署名検証（apksigner verify）
- 純正同 OEM の APK と diff
- VirusTotal 提出（ハッシュベース）
④ SafetyNet／Play Integrity（4 項目）
1. Play Integrity API テストアプリインストール
2. requestIntegrityToken 実行
3. サーバ側で deviceIntegrity / appIntegrity 確認
4. MEETS_DEVICE_INTEGRITY 取得できるか
MEETS_DEVICE_INTEGRITY 取得不可は要警戒（Bootloader 解錠／OS 改造／GMS 非認証）。
⑤ ファームウェア／Bootloader（3 項目）
1. Verified Boot 状態（dm-verity）
2. AVB（Android Verified Boot）公開鍵チェック
3. recovery イメージのハッシュ照合（OEM 公開値があれば）
中華格安機種は OEM 公開ハッシュが提供されていないことが多い。提供なしの時点で B ランク以下。
検出時の判定フロー
24 項目すべて純正一致 → 受入合格
↓
1-3 項目 不一致 → 詳細解析（情シス＋セキュリティチーム）
↓ 説明可能（純正カスタム等）
合格＋備考記録
↓ 説明不能
不合格＋返品手続
↓
4 項目以上不一致 → 即不合格＋OEM ブラックリスト追加
運用工数と頻度
| 端末数 | 全数検査工数 | 抜取検査（10%）工数 |
|---|---|---|
| 10 台 | 5-10h | 1-2h |
| 50 台 | 25-50h | 5-10h |
| 100 台 | 50-100h | 10-20h |
| 500 台 | 250-500h | 50-100h |
抜取で十分なケース（信頼ある OEM・継続発注）と全数検査が必要なケース（新規 OEM・初回発注・業務クリティカル用途）を分ける。
よくある質問（FAQ）
Q. 24 項目すべて自社で実施できるか？ A. ① ADB／② 通信ログ／③ APK／④ Play Integrity は情シス内製可能。⑤ ファームウェアは専門業者依頼が現実的。完全内製でも 75% 網羅できる。
Q. 検査ツールの推奨は？ A. ADB（Android SDK 同梱）、Wireshark、jadx、apksigner、apktool、VirusTotal API。すべて無償／OSS。
Q. 1 端末 30-60 分は現場運用に厳しすぎないか？ A. 信頼ある OEM の継続発注はチェックリスト④⑤を抜粋（10 分程度）に簡略化。新規 OEM／初回発注のみ全 24 項目実施。
Q. クラウド型検査サービスはあるか？ A. CrowdStrike Mobile Threat Defense や Lookout 等の Mobile Threat Defense 製品で一部自動化可能。中堅企業は内製＋部分商用が費用対効果バランス良。
参考資料
- Android Verified Boot 公式ドキュメント
- Google Play Integrity API 公式ドキュメント
- IPA「Android アプリのセキュアコーディングガイド」改訂版
- MITRE ATT&CK Mobile Tactics
Sandbox 検証環境の構築支援、24 項目チェックリストの内製化トレーニング、OEM ブラックリスト運用設計は GXO の端末セキュリティ運用サービスで対応可能です。
<!-- GXO_QUALITY_REWRITE_20260507_START -->GXO実務追記: AI開発・生成AI導入で発注前に確認すべきこと
この記事のテーマは、単なるトレンド紹介ではなく、業務選定、データ整備、セキュリティ、PoCから本番化までの条件を決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。
まず決めるべき3つの論点
| 論点 | 確認する内容 | 未整理のまま進めた場合のリスク |
|---|---|---|
| 目的 | 売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか | 成果指標が曖昧になり、PoCや開発が終わっても投資判断できない |
| 範囲 | 対象部署、対象業務、対象データ、対象システムをどこまで含めるか | 見積もりが膨らむ、または重要な連携が後から漏れる |
| 体制 | 自社責任者、現場担当、ベンダー、保守運用者をどう置くか | 要件確認が遅れ、納期遅延や品質低下につながる |
費用・期間・体制の目安
| フェーズ | 期間目安 | 主な成果物 | GXOが見るポイント |
|---|---|---|---|
| 事前診断 | 1〜2週間 | 課題整理、現行確認、投資判断メモ | 目的と範囲が商談前に整理されているか |
| 要件定義 / 設計 | 3〜6週間 | 要件一覧、RFP、概算見積、ロードマップ | 見積比較できる粒度になっているか |
| PoC / MVP | 1〜3ヶ月 | 検証環境、効果測定、リスク評価 | 本番化判断に必要な数値が取れるか |
| 本番導入 | 3〜6ヶ月 | 本番環境、運用設計、教育、改善計画 | 導入後の運用責任と改善サイクルがあるか |
発注前チェックリスト
- AIで置き換える業務ではなく、成果が測れる業務を選んだか
- 参照データの所有者、更新頻度、権限、機密区分を整理したか
- PoC成功条件を精度、時間削減、CV改善、問い合わせ削減などで数値化したか
- プロンプトインジェクション、個人情報、ログ保存、モデル選定のルールを決めたか
- RAG/エージェントの回答を人が監査する運用を設計したか
- 本番化後の費用上限、API使用量、障害時フォールバックを決めたか
参考にすべき一次情報・公的情報
- 経済産業省 AI事業者ガイドライン関連情報
- デジタル庁 AI関連情報
- OpenAI Platform Documentation
- Anthropic Claude Documentation
- OWASP Top 10 for LLM Applications
上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。
GXOに相談するタイミング
次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。
- 見積もり依頼前に、要件やRFPの粒度を整えたい
- 既存ベンダーの提案が妥当か第三者視点で確認したい
- 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
- 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
- PoCや診断で終わらせず、本番導入と運用改善まで進めたい
<!-- GXO_QUALITY_REWRITE_20260507_END -->Android 端末 サプライチェーン攻撃 事前検証 チェックリスト 2026｜納品前 Sandbox テスト 24 項目を自社条件で診断したい方へ
GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。
※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。