危険な端末を探す
端末の危険カテゴリーは、次の3つに分類できます。このページでは、上の表の a. b. の端末を見つける方法について述べます。
a. 端末が盗まれた。脱獄された。ルート化された。 b. 端末が長期間、MobiControlサーバにアクセスしていない。
従って、端末への働きかけや管理ができない。c. 情報漏洩を防止するための構成プロファイルが適用されていない。
盗まれたときを想定しての構成プロファイルが適用されていない。
c. の構成プロファイルが適用されてない端末を抽出する方法は、 「B-1. インストールに成功していない構成プロファイルの端末」を参照ください。A. 「脱獄」 または 「ルート化」している端末を見つける
(図1)
(図1)は、端末一覧のサンプルです。この中で、 端末プロパティの「OSセキュア」の値が、① 「いいえ」になっている端末があります。 この端末は、Androidでは「ルート化」、iPhone/iPadなら「脱獄」されています。
(図1)のように、コラムに「OSセキュア」を表示する方法は、「端末一覧の端末プロパティの入れ替え」を参照ください。 端末台数が多い場合、端末一覧から、OSセキュアの値を、1台ずつチェックするのは、大変です。(図2)
その場合は、(図2)のようなフィルタ条件を適用します。このフィルタ条件を適用すると、「OSセキュア」が「いいえ」になっている端末だけが表示されます。
フィルタ条件式については、「コンソールでの端末フィルタ」を参照ください。 しかし、「OSセキュア」が「いいえ」の端末を探すために、頻繁に(図2)のフィルタ条件式を適用するのは、実践的ではありません。 その替わり、端末一覧の上部に表示されるグラフの1つの端末プロパティを「OSセキュア」にしておきます。(図3)
(図3)のFalseの部分が、「脱獄」または「ルート化」された端末です。
本来、この端末台数はゼロになっていなければなりません。 従って、(図3)を表示しておけば、「脱獄」または「ルート化」された端末があることに、すぐ気が付きます。
(図3)での「不明」の棒は、Android、iOS/iPad以外の端末を示します。
(図3)で、「False」の棒が現れたら、(図2)のフィルタ条件式を適用し、該当端末を見つけてください。 グラフが示す「端末プロパティ」を変更する方法は、「グラフが示す端末プロパティの変更」を参照ください。 (図1)の② の端末モードの値を見てください。「UnenrolledByUser」となっています。 これは、端末ユーザが、MobiControlエージェントをアンインストールなどして、MobiControlから脱退(登録解除)した端末です。 この端末の 端末アイコンの左側に、エクスクラメーション・マーク(びっくりマーク)が付いています。従って、すぐ気が付くことができます。端末ユーザにコンタクトして、アンインストールした理由を尋ねてください。 Apple端末またはAndroid端末のMobiControlサーバへの登録を、端末側操作では、解除させないようにする方法があります。
UnenrolledByUser になる理由の一つとして、端末が、「脱獄」または「ルート化」したことも考えられます。
- 端末側から登録解除をさせない方法
端末を、電源オフとしておくと、MobiControlサーバにチェックインしません。 iPhone/iPadがMobiControlサーバに、7日間チェックインしないと、MobiControlサーバは、「脱獄」をしたとみなして、登録解除をすることがあります。 この場合も、「UnenrolledByUser」となります。B. オフラインになってから、長期間経つ端末を見つける (Apple端末、Windows Modernを除く)
MobiControlサーバに接続中の端末は、コンソールの端末一覧では、または、
と緑色の アイコンで表示されます。これが、正常です。
または、
とグレイのアイコンで表示されている端末は オフラインの状態です。 端末には、MobiControlエージェントがインストールされています。 Apple端末以外のMobiControlエージェントは、チェックイン・スケジュールを内蔵しています。時刻になれば、 MobiControlサーバにチェックインします。
しかし、端末が、MobiControlサーバとの間で、オフラインの状態だと、チェックインができません。 一方、コンソールで設定した「構成プロファイル」「ルール」「(Wipeなどの)働きかけ」などは、端末からのチェックインがないと、端末に向けて送れません。
オフラインになっているのは、なんらかのインシデントが起きた場合です。 「電源オフ」、「WiFiと接続していない」、「携帯電話回線が圏外」の場合が考えられます。 端末はスリープ中(ロック中)でも、接続しているのが常態です。(図4)
(図4)の② の「エージェント切断時間」の列を参照ください。 「エージェント切断時間」とは、オンラインだった端末が、MobiControlサーバから最後に切断した日時を示しています。 ③ の2台の端末が、他の端末に比べて、切断してから、かなり長い期間が過ぎているのが分かります。これは、異常です。
(図4)で、コラムの「エージェント切断時間」タイトルの右端の下向き矢印を押すと、日時の若い順に、端末を並べることができます。 エージェント切断日時が古くなるほど、下の方に表示されます。オフライン時間が長い端末を、見つけやすくなります。Apple端末のチェックインは、他の端末のそれと異なる仕組みです。MobiControlエージェントでなく、Apple端末のOS が内蔵している「MDMプロトコル」によるチェックインです。端末が、長い期間、オフラインである原因の一つに、盗難が疑われます。 WiFi専用端末では、接続できるWiFi/SSID を固定している場合があります。会社が認めているWiFi/SSID にしか接続できないように しているのが普通です。オフラインであるのは、会社施設以外に、端末が持ち出されていることが疑われます。 端末台数が多い場合に、「エージェント切断時間」が示す日時を、(図4)で、1台ずつチェックするのは、実践的ではありません。 その替わり、端末一覧の上部に表示されるグラフの1つの端末プロパティを「エージェント切断時間」にしておきます。(図5)が、それです。 グラフが示す「端末プロパティ」を変更する方法は、「グラフが示す端末プロパティの変更を参照ください。
必須ではありませんが、Apple端末にも、MobiControlエージェントをインストールできます。しかし、その役割は補助的です。 従って、MobiControlエージェントによる接続が、永らくなくても、クリティカルではありません。従って、(図4)のフィルタ条件は、 ① のように、端末ファミリ = AndroidPlusとしています。
端末ファミリ = AndroidPlus のフィルタ条件式では、 Android Plus と Android Enterpriseの両方の端末を、端末一覧に表示できます。詳しくは、「コンソールでの端末フィルタ」を参照ください。
(図5)
「エージェント切断時間」は、端末が、MobiControlサーバから切断してからの経過時間を指します。
(図5)の横軸の単位は、時間です。 現在を0とし、過去に向かって、1時間、2時間、・・と24時間前までを表示しています。
縦軸は、端末台数です。
(図5)では、MobiControlサーバから切断して、1時間以内の端末が2台あることを示しています。
24時間以上前に切断した端末、つまり24時間以上オフラインの端末は、「不明」の棒に含まれます。 「不明」の台数が多いのは、問題です。 「不明」の台数が多くなれば、(図4)で、24時間以上オフラインの端末を見つけます。そして、 端末ユーザにコンタクトして、電源をオフにしていないかなどを訊いてください。 現在、MobiControlサーバに接続中の端末は、(図5)には表示されません。 例え、エージェントの最終切断時刻が、過去24時間以内でも、Windows Modernとして設定したPCは、(図5)で常に「不明」にカウントされます。 (Windows Classicとして設定したPCのオフライン期間は、Android等と同じく、時間単位で表示されます)
フィルタ条件式を、(図6)のようにしておくと、端末一覧から、Windows Modernとして設定したPCは、表示除外されます。 従って、(図5)の「不明」には、Windows Modernは含まれなくなります。(図6)
Android端末がオフラインになる主な原因
Android端末は、スリープ状態になっても、MobiControlエージェントは、バックグラウンドで起動を続けるのが仕様です。 従って、端末が、スリープ状態になっても、MobiControlサーバとは、オンラインを維持します。
しかしながら、バッテリー消費を抑える目的で、スリープ状態になると、MobiControlエージェントを停止したり、 そのオンラインを停止したりする端末があります。 これの対策は、常にサーバとの接続を維持 を参照ください。C. 永らくチェックインをしてこないApple端末を見つける
Apple端末は、通常オフラインになっています。チェックイン・スケジュールは、MobiControlサーバが保有しており、時刻になれば、 Apple APNs経由で、端末にチェックインを要求します。
MobiControlサーバは、通常、2時間に1回の頻度で、端末OSが内蔵するMDMプロトコルに、チェックインの要求を出します。 従って、端末は、2時間に1回の頻度でチェックインをしてきます。(詳しくは、「更新スケジュールの設定」を参照ください。)
コンソールで設定した「構成プロファイル」「ルール」「(Wipeなどの)働きかけ」などは、端末からのチェックインがないと、端末に向けて送れません。(図7)
(図7)の② の「MDMステータス更新」の列を参照ください。 「MDMステータス更新」とは、Apple端末が、MobiControlサーバに、最後にチェックインした日時です。 ③ の端末の「MDMステータス更新」日時が、他の端末のそれに比べて、かなり古いことが分かります。これは、異常です。 端末はスリープ中(ロック中)でも、スケジュール時刻になれば、チェックインするのが正常です。
他の端末の「MDMステータス更新」の日時より55時間以上古くなっています。 これは、55時間以上に渡って、チェックインができない事態が、③ の端末に発生したことが、推測できます。
「電源オフ」、「WiFiと接続していない」、「携帯電話回線が圏外」の状態が、55時間以上継続していることが考えられます。 端末台数が多い場合に、「MDMステータス更新」が示す日時を、(図7)で、1台ずつチェックするのは、実践的ではありません。 その替わり、端末一覧の上部に表示されるグラフの1つの端末プロパティを「MDMステータス更新」にしておきます。(図8)が、それです。 グラフが示す「端末プロパティ」を変更する方法は、「グラフが示す端末プロパティの変更を参照ください。
(図8)
(図8)は、最後のチェックインから何時間経過しているかを示しています。 (図8)の横軸の単位は、時間です。 現在を0とし、1時間、2時間、・・と24時間までを表示しています。
縦軸は、端末台数です。
最後のチェックインから24時間以上経過した端末は、「不明」の棒に含まれています。
「不明」の台数が多いのは、問題です。 「不明」の台数が多くなれば、(図8)で、24時間以上オフラインの端末を見つけます。そして、 端末ユーザにコンタクトして、電源をオフにしていないかなどを訊いてください。 長期間、チェックインがない理由の1つに、端末での「脱獄」も疑われます。
iPhone/iPadが、7日以上、チェックインしてこない場合は、それが脱獄されたと解して、 MobiControlサーバは、その端末を強制的に登録解除することもあります。
例え、端末ユーザが、端末を7日間、全く操作しなかったとしても、そうなります。 7日間もチェックインがないのは、異常だからです。 (図8)の「不明」には、Apple端末以外の全ての端末台数も積み増しされます。
しかし、(図7)の、① のように、フィルタ条件式 を、
端末ファミリ = Apple
としておくと、端末一覧には、Apple端末しか表示されません。 従って、(図8)の「不明」に、Apple端末以外が積み増しされることはありません。
詳しくは、「コンソールでの端末フィルタ」を参照ください。 Apple端末のチェックインの仕組みは、「Apple端末:チェックインと接続」を参照ください。D. オフラインになってから、長期間経つWindows Modern エンドポイントを見つける
D-1. オフライン期間が長いエンドポイントを、メール通報
エンドポイントが、Windows Modernとして設定したPCの場合、(図4)の「エージェント切断時間」の値は、「該当なし」と表示されます。 従って、オフライン期間が長いエンドポイントを、(図4)で見つけることはできません。
そこで、オフライン期間が長いエンドポイントがあれば、それを、関係者にメール通報する方法を、下記に説明します。(図9)
(図9)は、Windows Modernのアラートルールの設定での、アラートイベントを指定する画面です。(図9)の表示方法は、 「Windows Modern:アラートルールの作成」の 「4.端末の動作結果に関するイベント」を参照ください。
- (図9)の① にチェックを入れます。
- ② に、数値を入力します。単位は、「分(Minutes)」です。オフラインになってから、何分間経てば、アラートメールを発報するかを指定します。 1440は、24時間です( = 60 X 24)。2880は、48時間です。
- ③ にもチェックを入れます。③ にチェックを入れておくと、 該当のエンドポイントがオンラインになるまで、1時間に1回、アラートメールを発報します。 アラートメール発報は、1回だけでよいとする場合は、③ には、チェックを入れません。
- 「アラート文(編集可)」の文章を編集します。
デフォルトの文章: 「これまで%MINUTES%時間、端末が未接続」
編集後の文章: 「これまで、%DAYS%日間、または%MINUTES%分間、端末が未接続」
(図10)が、編集後の例です。このように編集しておくと、受信するメール本文のアラート文は
例えば、 「これまで、8.2日間、または11824分間、端末が未接続」という文章に変換されます。(図10)
(図9)での② は、(図10)では、2880 としています。つまり、48時間経過を、「しきい値」としています。適宜、変更ください。アラートルールを設定すると、(図11)で、指定した宛先に、アラートメールが送られてきます。 エンドポイントがオフラインになってから、(図9)の② で指定した分数を経過すると、送られてきます。
- (図11)で、「メールのプロファイル」や「メール宛先」を指定します。
(図11)
(図11) の表示方法は、「電子メールプロファイルの作成」を参照ください。
(図10)や(図11)の編集例の場合、次の様な本文のメールが送られてきます\\名古屋支店\企画部 の Windows73 で
これまで、8.5日間 または12184分間、端末が未接続が、2021/07/23 21:04:21 に発生。ここで、Windows73は、端末一覧での端末の名前
D-2. 正常性構成証明書の受信から、長い期間経過したエンドポイントを抽出
(図12)のようなフィルタ条件式を入力すると、コンソールの端末一覧には、正常性構成証明書の最後の受信日時が、 7月22日以前であったWindows Modern エンドポイントのみを、抽出表示します。Windows Modernのエンドポイントが、MobiControlサーバにチェックインすると、 MobiControlサーバは、MicrosoftのDHA(Device Health Attestation)サーバから、正常性構成証明書を取得します。(図12)
(DHAサーバを、オンプレミスで用意してあれば、そのオンプレミスのDHAサーバから、正常性構成証明書を取得します。) (図13)は、コンソールで、個別のWindows Modern エンドポイントを選択したときに、表示される「端末の詳細」タブの右下部分です。
(図13)
(図13)の「最終レポート日」に記されている日時は、 Microsoft DHAサーバが、正常性構成証明書を作成した日時です。 (図14)は、Windows Modernの「イベントログ」タブを開いたときに表示されるログのサンプルです。エンドポイントからのチェックインの2秒後に、MobiControlサーバが、 ヘルス証明書(=正常性構成証明書)を受信したことが分かります。 従って、正常性構成証明書の最後の受信日時は、ほぼ、Windows Modernエンドポイントの最後のチェックイン日時とみなすことができます。 正常性構成証明書の最後の受信日時から、一定期間経過しているエンドポイントだけを、端末一覧に抽出表示するフィルタ条件式の作成方法を 説明します。 下記の「正常性構成証明書の最後の受信日時が指定日時以前のエンドポイントを抽出する」をクリックしてください。(図14)
(図15)
赤矢印部分にマウスを載せ、クリックします
(図16)
プルダウンメニューが現れるので、「ヘルス検証」を選択します。
(図17)
プルダウンメニューが現れるので、「最終レポート日」を選択します。
(図18)
プルダウンメニューが現れるので、「以下」を選択します。「以下」は、指定日時より、「古い」を指します。
(図19)
カレンダーが現れるので、月日を指定し、「完了」ボタンを押します。
(図20)
フィルタ条件式の完成です。 フィルタ条件式の入力が終わると、右端に、が、現れます。 これを押すと、フィルタ条件式を充たす端末群が表示されます。
ここでは、正常性構成証明書の最後の受信が、指定日時より以前であったエンドポイント群のみを、コンソールの端末一覧に抽出表示します。 「端末の詳細」タブの右下部分が、(図13)と異なり、(図21)のように表示されているエンドポイントPCがあることがあります。
(図21)
Microsoft DHAサーバは、 (図21)のように表示されているエンドポイントの正常性構成証明書を、作成できていません。
従って、MobiControlサーバも、それを受信できていません。
この場合、(図20)のようなフィルタ条件式を適用しても、当該エンドポイントは抽出表示されません。
(図21)のエンドポイントは、MobiControlサーバに、永らくチェックインしていないという問題とは、別の重大な問題を抱えています。 それは、エンドポイントの、セキュリティ脆弱性に関する情報を、入手できなくなっているからです。 一部のウィルス対策ソフトをインストールすると、それが、Microsoft DHAサーバに、セキュリティ脆弱性に関する情報を、送ることを阻止することがあります。
ウィルス対策ソフトとして、Windows Defenderを適用している場合、 これが、Microsoft DHAサーバに、セキュリティ脆弱性に関する情報送信を阻止することはありません。 正常性構成証明書の詳細に関しては、「デバイス正常性構成証明書」を参照ください。
