MDM・MAM・アプリ解析と端末紛失への対応

業務端末を紛失したら、遠隔消去の指示だけでアクセスを止められるでしょうか。端末管理と、サーバ側の認証・認可を確認します。

営業担当者のタブレットを紛失した。同じ業務アプリの配布物から、全利用者に共通のAPIキーも見つかった。端末の遠隔消去を指示しただけで、顧客情報へのアクセスは止まるだろうか。

MDM・MAMの管理範囲、アプリ解析で分かること、サーバ側が直ちに実行すべき失効と認可を、一つの事例で確かめる。

誰が、どの場所で判断するのか

A社は業務アプリField-1で顧客案件を閲覧する。社給タブレットTAB-41はMDM登録済みで、私物端末BYOD-52には管理対象のField-1だけにMAMを適用する。両端末はIdPから利用者別トークンを得てAPI-1へ接続する。

API-1は案件CASE-41の担当者を毎回確認する設計のはずだが、旧実装にはアプリ全体で共通のAPIキーK-publicを受理する経路が残っている。

09:10にTAB-41を紛失し、端末はオフラインになった。09:15にMDMからロックと消去を指示したが、適用確認はない。09:17にIdPでTAB-41の更新用資格とセッションを失効し、API-1にも端末IDを拒否する規則を反映した。

09:20にはField-1の配布物を解析した担当者がK-publicを発見した。端末紛失と共通キー漏えいは別の事故経路として調べる。

MDMはTAB-41の端末状態、MAMはField-1内の業務データを主に制御する。IdPは資格の発行・更新・失効、API-1はトークン、端末状態に基づく方針、案件の閲覧権限を判断する。

K-publicだけでCASE-41を読める旧経路があれば、この分担が崩れる。

この事案を読むために、どの用語を押さえるか

端末の登録、構成、パスコード、暗号化、利用制限、ロック・消去などを管理する仕組み。登録端末の状態は扱えるが、APIの顧客別認可を代行しない。
対象アプリの業務データにコピー・保存先・共有先などの制約を適用する管理。製品によっては端末登録なしでも利用できる。アプリ外に既に持ち出されたデータは回収できない。
配布物の静的解析と、許可された試験環境での動的解析。定数・設定・保存先・通信を調べる。クライアントの観測だけでサーバの認可が正しいとは証明できない。
APK・IPAなどにAPIキーや共通パスワードを同梱すること。配布済みアプリは解析できる前提で扱い、全利用者に共通の値を真正な利用者の証拠にしない。
client_idはアプリを識別する公開値。配布するネイティブアプリ内の固定client_secretは機密を保てないため、秘密を保持できるクライアントとして扱わない。
APIへ提示する有効期限と権限を持つ資格情報。短命でも有効期間中の利用をどう止めるかは、APIの検証方式と失効設計による。
新しいアクセストークンの取得に使う資格情報。端末紛失時は該当セッションや端末単位で失効し、再発行を止める。既発行のアクセストークンとは別に扱う。
OSが提供する鍵・資格情報の保護機能。端末内トークンの抽出難度を上げるが、アプリに埋め込んで配布した共通鍵を秘密にはできず、侵害済みプロセスによる利用まで必ず防ぐものでもない。
私物端末の業務アプリだけを管理し、業務データを削除する運用。全端末消去の可否は端末所有、登録方式、事前同意と製品機能による。
OS状態・管理登録・アプリの正規性などのシグナル。偽装や取得不能、判定遅延を考慮し、利用者認証と顧客別認可の代わりにしない。

正常なときは、どの順序で処理されるか

配布するField-1を公開クライアントとして扱い、固定の共通秘密を認証に使わない。利用者は外部ブラウザを使う認可コード方式とPKCEでログインする。
IdPは利用者と端末・セッションを関連付けて短命のアクセストークンと保護された更新用資格を発行する。トークンは必要な権限に絞り、秘密をURLや平文ログに記録しない。
Field-1はOSのKeystore・Keychainで端末内資格を保護し、機微なオフラインキャッシュを最小化する。社給端末はMDMで画面ロックと暗号化、対象アプリはMAMで業務データの共有先を制限する。
API-1はトークンの署名・発行者・受け手・期限・権限を検証し、CASE-41への担当者権限をリクエストごとに確認する。端末状態は追加の許可条件とし、キーやアプリ識別子だけで顧客情報を返さない。
紛失を想定して端末別資格失効、API側の即時拒否、管理命令の適用確認、監査ログの照合を定期的に演習する。

PKCEは認可コード横取りへの対策であり、改造されたアプリを無条件に信頼できる仕組みではない。端末内の資格保護とサーバ側の利用者・案件認可は両方必要になる。

設定値とログから、何が分かるか

TAB-41とBYOD-52、社給か私物か、登録方式、紛失申告の対象を確認する。端末ID文字列だけを認証根拠にしない。
管理サーバへの最終接続とロック・消去命令の送信、受信、成功を区別。queuedは適用済みを意味しない。
Field-1にMAMが適用された利用者とアプリ版を確認。対象外アプリへの共有、画面保存、OSバックアップ等の扱いも調べる。
資格と端末・利用者・発行時刻・失効時刻を関連付ける監査用識別子。実トークン値はログに残さない。
許可操作、対象API、期限を表す。短命でも有効なアクセストークンをAPIがどう拒否するかは別設計。
APIで認証した利用者、対象案件、担当者権限、許可・拒否の結果。キーが正しいだけで閲覧を許可しない。
共通キーの識別子、含まれるアプリ版、API側の受理範囲。値そのものを証拠やログに貼らない。
端末に保存した案件情報、最終同期、アプリ内の保護状態。API停止後も既存のオフラインデータは残り得る。

MDM、IdP、API、解析記録を時刻順にまとめたもので、実製品のイベント名ではない。時刻同期と欠落期間を調べてから因果関係を判断する。

text

09:10 source=service event=lost_report device=TAB-41
09:11 source=mdm device=TAB-41 last_check_in=09:08 state=offline
09:15 source=mdm device=TAB-41 command=lock,wipe state=queued
09:17 source=idp device=TAB-41 session=S-41 refresh=revoked
09:17 source=api device=TAB-41 policy=deny result=active
09:18 source=api device=TAB-41 token=T-41 case=CASE-41 result=403
09:20 source=review app=Field-1 version=4.2 key_id=K-public found=true
09:22 source=api auth=legacy-key key_id=K-public case=CASE-41 result=200

09:18の403はそのAPI要求が拒否された証拠である。09:15のqueuedは端末が消去された証拠ではない。

09:22の200は旧キー経路が生きていたことを示すが、誰が呼び出したか、どのデータが返ったかは応答量、主体、案件、通信元などの記録を追加して調べる。

攻撃が成立するのは、どの条件か

状態・攻撃	成立条件、証拠、対策の位置
紛失端末のオフライン閲覧	端末が未消去でローカルキャッシュが残り、解除できる場合に成立し得る。キャッシュ量、暗号化、画面ロック、最終同期を調べる。API拒否だけでは端末内データは消えない。
既発行アクセストークンの利用	更新用資格を失効しても既発行の短命トークンはAPI設計次第で期限まで使える。API側の端末拒否、参照型トークンの失効照会、短い期限等を組み合わせる。
共通キーの抽出	配布物の静的解析で固定値が見つかれば、端末を所持しなくても同じ値を再利用できる。難読化は抽出コストを上げるだけで、秘密の保持を保証しない。
案件IDの差替え	APIがログインだけを確認してCASE-41の担当者権限を見なければ、別利用者の案件を取得できる。サーバで対象オブジェクトごとに認可し、別案件で拒否試験する。
MAM対象外への持出し	許可しない共有先や管理対象外アプリ、画面・写真、既存エクスポートから流出し得る。MAMの適用範囲と製品・OSの制約を確認する。
完全性判定の過信	正規署名や端末完全性の判定は補助的なシグナル。改変・偽装・判定遅延を想定し、APIの認証・認可・レート制限を省略しない。

端末紛失はローカル情報へのアクセス、資格の再利用、API利用という別の経路を持つ。共通キー漏えいは配布した全アプリ版に波及し得るため、紛失したTAB-41だけを無効化しても対処できない。

判断を確かめるために、何を調べるか

判定段階	必要な証拠と結論の上限
端末の状態	登録情報、最終チェックイン、消去命令の受信・成功、回収状況を確認。queuedなら適用未確認と書く。
端末内の情報	キャッシュ対象と件数、最終同期、OS・アプリの暗号化とロック設定を確認。実際の閲覧は別の証拠を要する。
資格の利用	IdPの発行・更新・失効とAPIの成功・拒否をトークンIDと端末で照合。更新停止と既発行トークンの拒否を分ける。
共通キーの範囲	配布版、解析結果、APIのキー受理ログ、キー利用による応答を確認。キー発見だけで第三者利用を断定しない。
顧客データの取得	APIの案件ID、主体、応答コード、返却件数・量、転送記録を確認。200だけで閲覧範囲や持出し主体を決めない。
封じ込めと再開	旧キー拒否、端末拒否、正規利用者の再認証、顧客別認可、監査の継続を別々に試験する。

静的解析では配布用パッケージを展開し、文字列、設定ファイル、アセット、URL、証明書、権限宣言、ローカル保存処理を調べる。難読化で名前が変わっても、実行時にAPIへ渡す固定値は端末側で利用可能でなければならない。

アプリ署名は配布物の出所や改ざん確認に役立つが、内部の固定秘密を隠す機能ではない。

動的解析では許可されたテスト端末とテストアカウントを用い、起動、ログイン、端末ロック、オフライン閲覧、通信、ログアウト後の保存状態を観測する。TLS検証を弱めた本番アプリを配布して調査してはいけない。

クライアント側で操作ボタンが消えていても、APIへ直接要求すればサーバ側の認可不足は露見し得る。

client_id、公開APIエンドポイント、公開鍵のような公開前提の設定と、秘密として認証に使う値は区別する。ネイティブアプリに埋めた全利用者共通のclient_secretやAPIキーは、配布先から抽出され得る。

必要なサーバ秘密はサーバ側に置き、個々の利用者の権限はトークンとAPIの認可で判定する。

Keystore・Keychainに格納した鍵が非抽出可能でも、端末を操作できる攻撃者や侵害されたアプリが鍵操作を呼べる場合がある。OSの保護、利用者認証要求、バックアップ可否、アプリのアクセスグループ等の設定を確認する。

保存先の保護は認可を置き換えず、紛失時にはサーバ側で資格を止める。

アクセストークンが自己完結型でAPIが期限と署名だけを確認する場合、IdPでリフレッシュトークンを失効させても、既発行トークンは期限まで通る可能性がある。

即時停止が必要ならAPI側で端末・セッション拒否リストを参照する、短命化する、参照型トークンの状態を照会するなどの設計が要る。各方式には可用性と遅延の影響がある。

端末完全性やアプリ正規性の判定は、サーバで要求内容と結び付けて検証し、期限・再利用・判定不能時の扱いを決める。これはリスク評価を強める材料だが、正しい利用者に見える要求でもCASE-41を読めるかは別に認可する。

端末IDやアプリ署名だけから顧客の担当者を推定しない。

MAMは管理対象アプリのコピー・保存・開く先を製品とOSの能力内で制御する。既にメール送信、撮影、エクスポートされた情報や、管理対象外に移ったデータの回収はできない。

BYODでは所有者の私的データとの境界と同意を先に決め、業務データの選択的消去とサーバ側失効を組み合わせる。

遠隔消去命令は端末が管理サービスへ再接続したときに届き、実行される。オフライン中のTAB-41にqueuedを表示しても、消去の成功もローカルキャッシュの非閲覧も証明しない。

IdP・APIで先に資格を止め、後で適用状態と返却端末の実物を確認する。

共通キーを除去すると、更新前の正規アプリが使う旧経路も止まる。緊急時は旧キーの利用元と業務依存を確認してサーバで受理を停止し、必要なら新しい認証経路への更新を配布する。

キーをアプリだけで差し替えても、新しい固定値が再び配布物から抽出されるので根本対策にならない。

設定変更や例外運用では、何に注意するか

運用場面	崩れやすい条件と確認
オフライン端末	ロック・消去の指示は保留される。管理画面の送信成功と端末側の適用成功を別項目で監視する。
BYOD退職・紛失	私物全体の消去は所有者の同意や登録方式を確認する。管理対象アプリの選択的消去とIdP・APIの失効を組み合わせる。
通信不能・古い端末	準拠性情報が古いときの許可・拒否と猶予期間を決める。例外を恒久化せず、監査できる期間に限定する。
アプリ更新	旧版に残るK-publicの受理停止時刻と更新率を管理する。アプリ内の値を再配布するだけでは秘密にならない。
ローカルバックアップ	業務キャッシュがOSバックアップや共有領域に残るか、管理ポリシーと実機で確かめる。消去対象の範囲を明記する。
権限変更・異動	担当案件が変わっても古いトークンやオフラインキャッシュが残る。APIの権限再評価とキャッシュ削除の契機を決める。

MDM登録台数、MAM保護対象アプリ、IdPの端末別セッション、APIの案件別許可を同じものとして数えない。監査では対象母数と適用時刻をそろえて、管理外端末・旧アプリ版・古いセッションを探す。

被害を止め、再開するには何を確認するか

サーバ側の端末拒否とK-public廃止は遠隔消去の適用を待たない。ロック・消去を依頼しても、オフライン端末の保存済み情報には別のリスクが残る。順序と成功確認の証拠を分ける。

紛失申告、端末所有、最終チェックイン、キャッシュ、IdPの資格、APIの利用、K-publicを含む配布版と利用記録を保全する。
TAB-41の更新用資格・セッションを失効し、API-1で同端末の既発行資格を拒否する。拒否反映時刻と旧トークンでの403を確認する。
K-publicを受理する旧経路をサーバで停止し、全配布版への影響を調べる。共通キーでのアクセスを拒否し、担当者権限のないCASE-41要求も拒否する。
MDMへ社給端末のロック・消去を指示し、後で実行結果を確認する。BYODに波及した場合は事前同意と方式に従い業務データの選択的消去を行う。
返却または交換端末を再登録し、旧資格は拒否、新資格で自分の案件のみ取得可能、他人の案件は拒否、MAMと監査が適用済みであることを試験する。

09:22のK-public利用成功が見つかっても、紛失者が操作したのか配布物から第三者が抽出したのかは、その記録だけでは決まらない。端末内キャッシュの実際の閲覧も別証拠が必要である。影響報告では確認済み、可能性あり、記録不足を分ける。

設問の条件を、どう答案へ結び付けるか

科目Bの設問では、管理命令の発行と適用、更新用資格の失効と既発行トークンの拒否、配布物の秘密と利用者別資格、端末内データとAPI取得をそれぞれ別の事実として読む。対策は『どの主体が、どの資源に対し、いつ、何を拒否するか』まで書く。

MDMの端末管理、MAMのアプリデータ管理、IdPの資格管理、APIの案件別認可を分ける。
queuedと適用済み、鍵発見と第三者利用、API 200と取得データ量を区別する。
配布物の共通秘密を真正な利用者の証拠にしない。
オフラインキャッシュ、BYOD、旧版アプリ、既発行トークンを例外として確認する。
復旧試験では旧資格の拒否と新資格の正規利用を両方確かめる。

短い演習で判断を確かめる

演習1：消去命令

条件：TAB-41はオフライン。MDM画面にはwipe=queued。

質問：顧客データは消去済みか。

解答：断定できない。端末側の適用確認がなく、API側の失効とキャッシュ範囲の調査を先行する。

誤答の理由：命令発行と端末での実行を混同している。

演習2：トークン失効

条件：09:17に更新用資格を失効。APIは自己完結型トークンの署名と期限だけを検証する。

質問：09:16発行のトークンは直ちに拒否されるか。

解答：限らない。API側の拒否規則や失効照会がなければ期限まで有効になり得る。

誤答の理由：更新停止を既発行トークンの失効と同一視している。

演習3：共通キー

条件：配布物からK-publicが発見され、APIの旧経路はキーだけで認証する。

質問：アプリで別の固定キーに差し替えれば十分か。

解答：不十分。新しい固定キーも配布物から抽出できる。旧経路を廃止し、利用者別資格とサーバ側認可に移す。

誤答の理由：配布されるネイティブアプリに共通秘密を隠せると考えている。

演習4：MAMとBYOD

条件：BYOD-52は端末登録なしでField-1だけMAM管理。

質問：端末の私的写真を含めて全消去してよいか。

解答：登録方式と同意を確認する。業務アプリの選択的消去とサーバ側資格失効を行う。

誤答の理由：MAMの対象と端末所有の境界を無視している。

演習5：案件別認可

条件：正規トークンでCASE-41を取得できた。別利用者の案件IDに変えても200。

質問：どこを直すか。

解答：APIで要求ごとに利用者の対象案件への権限を検証し、他人の案件を拒否する。

誤答の理由：アプリ画面でリンクを隠すだけでは直接API要求を防げない。

演習6：証拠の限界

条件：09:22にK-publicでAPI 200。端末消去は未確認。

質問：確定できる事実は何か。

解答：旧キー経路への要求が成功したこと。端末内キャッシュの閲覧者や、第三者によるキー抽出・利用は追加証拠が必要。

誤答の理由：成功応答から攻撃者やローカル閲覧まで決めつけている。

仕様を確認したいときの一次資料

NIST SP 800-124 Rev.2：企業のモバイル端末セキュリティ

Microsoft Learn：Intuneのアプリ保護ポリシー

Microsoft Learn：Intuneの選択的消去

RFC 8252：ネイティブアプリのOAuth 2.0

Android Developers：Android Keystore

Apple Developer：Keychain Services

OWASP MASTG：モバイルアプリの改変・リバースエンジニアリング

OWASP API Security：オブジェクト単位の認可

Android Developers：Play Integrity API