侵害状態のデバイスについて

はじめに

モバイル デバイスのおかげで、いつでも連絡がとれ、外出先からでも企業のコンテンツにアクセスできるようになりました。このようにモバイル デバイスが重要なビジネス情報フローの一端を担うようになった一方で、ネットワークへのマルウェアの侵入やデータの破損も起こりやすくなっています。こうした潜在的なセキュリティ リスクのもとで、企業のモバイル デバイス管理 (MDM) 戦略はさまざまな課題に対処できることが求められています。これらのセキュリティ上の課題のひとつに、企業が管理する多数のモバイル デバイスの中に混入した侵害状態のデバイスが挙げられます。

 

概要

侵害状態のデバイスには「ジェイルブレーク (脱獄)」された iOS デバイスや「ルート化」された Android デバイスが含まれます。これらはユーザーにより意図的に出荷時の状態から変更されたデバイスです。こうしたデバイスでは必要不可欠なセキュリティ設定が失われているため、マルウェアがネットワークに侵入し、企業のリソースにアクセスするのを許してしまう可能性があります。MDM 環境という「鎖」全体の強さは、最も弱い「環」で決まります。侵害状態のデバイスが 1 台あるだけで、機密情報の漏洩やサーバの障害につながる可能性があるのです。さまざまな種類のデバイスと OS が混在する BYOD (個人デバイスの業務利用) 環境では、侵害状態のデバイスの監視/検出はかなり困難な課題です。しかし、侵害状態のデバイスは企業にとってセキュリティ上の重大な関心事で、いますぐ取り組むべき問題でもあります。

ジェイルブレーク デバイスやルート化デバイスは基本的なセキュリティ機構が無効になっているため、次のような好ましくない行為に対する弱点になりえます。

  • パスワードや ID の盗難:暗号化されていないユーザー名やパスワードはたやすく盗まれ、より機密性の高い領域への侵入や企業を騙る「なりすまし」に利用されます。
  • データの傍受:通常のセキュリティ対策さえ施されていない送受信は、たやすく外部から覗き見られます。
  • ウイルスへの感染:保護されていないネットワークはウイルスやマルウェアの恰好の標的です。企業データの破損や喪失につながります。

検出の課題

侵害状態の検出に対するデバイスの挙動は、稼働しているプラットフォームの種類によって異なります。たとえば iOS 7 以降のデバイスでは、バックグラウンド チェックがサポートされていますが特有の制約もあります。一方、Android デバイスでは何の制約も制限もなしにバックグラウンド チェックを実行できます。この問題に対し、AirWatch のソリューションではデバイスや OS の種類に関係なく検出が可能になっています。

注:AirWatch Agent はさまざまな独自メカニズムを使用してデバイスが侵害状態かどうかを判定し、その結果をコンソールに報告します。また、状態が「非侵害」から「侵害」へと変化したことをきっかけに、自動的に特定の処理が実行されることもあります。何らかのデバイス ルート化プログラムが「非侵害」状態を偽装して報告してくる可能性とそこから生じるセキュリティ リスクを考慮し、デバイスがいったん侵害状態とみなされると、それ以降、そのデバイスからの侵害状態の報告は無視されます。この挙動は、デバイス ユーザーに割り当てられた企業データに対して最大限のセキュリティを提供するための設計であり、今後も変更されることはありません。

AirWatch のアプローチ

上記のようなさまざまなケースに対応するため、AirWatch は侵害状態のデバイスを検出するための、独自の重層的アプローチを開発しました。iOS および Android での機能と制限については、次の表を参照してください。

プラットフォーム別の機能

 機能

 iOS

 Android

Agent の加入

加入時に侵害状態を検出

加入時に侵害状態を検出

バックグラウンド チェック

iOS 7 以降のデバイスでは、AirWatch MDM Agent を使用してバックグラウンド チェックが可能

バックグラウンド チェックでの検出が可能

オンデマンドでのチェック

APNs メッセージのスケジュール送信を使用

- AirWatch SDK を使用するアプリの起動時

GCM/AWCM メッセージを使用

- AirWatch SDK を使用するアプリの起動時

順守エンジン

侵害状態のデバイスの検出時または順守状態が有効期限切れのときに対応措置を自動実行

侵害状態のデバイスの検出時または順守状態が有効期限切れのときに対応措置を自動実行

企業アプリ組み込みの検出

AirWatch SDK により企業アプリに侵害検出ロジックを組み込むことが可能

AirWatch App Wrapping によりラッピング アプリでの侵害検出の実行が可能

AirWatch App Wrapping によりラッピング アプリでの侵害検出の実行が可能

注:セルラー接続が可能な iOS 6 以前のデバイスでは、GPS 追跡が有効になっていれば、AirWatch MDM Agent を使用してバックグラウンド チェックが可能です。Wi-Fi 接続のみ可能な iOS 6 以前のデバイスでは、社内アプリに AirWatch SDK を組み込むことでバックグラウンド チェックが可能になります。

 

AirWatch での侵害デバイスの検出

AirWatch のソリューションは、管理対象外のデバイスを締め出したり、侵害状態や非順守状態のデバイスを切り離したりすることで、デバイスの加入から加入解除までのライフサイクル全体を管理下に置きます。弊社独自の検出アルゴリズムは、常に最先鋭の検出能力を発揮できるよう、絶えず侵入テストが実施され、また継続的に最新 OS に基づく研究開発がなされています。この重層的侵害検出アプローチは、次の要素から成り立っています。

Agent の加入

排除対象のデバイスに対する AirWatch の最初の防衛ラインは、加入のタイミングです。順守ルールを設定することで、侵害状態のデバイスをその加入前に検出することができます。すべてのデバイスにセキュリティ設定を順守させたり、デバイス ユーザーに代わって簡単にプロファイルをインストールすることもできます。セキュリティ順守状態の検出は、加入方法によって異なります。

  • Agent ベース - iOS/Android デバイスは、それぞれ iTunes App Store や Google Play ストアから AirWatch MDM Agent をダウンロードして加入できます。インストールされた Agent は、AirWatch コンソールで指定された間隔でデバイスの状態を調べ、その情報をデバイスからサーバに送信します。
  • Web ベース - 現時点では iOS デバイスだけが Web ベースの加入をサポートしています。これは、デバイスの既定の Web ブラウザで加入 URL を使用する加入方法です。これらのデバイスで侵害状態を検出するには、AirWatch SDK が組み込まれたアプリがデバイスにインストールされている必要があります (AirWatch MDM Agent、AirWatch Browser、AirWatch Content Locker、AirWatch SDK を組み込んだ企業アプリなど)。

各種加入方法の違いなどの詳細については、『iOS Platform Guide』(iOS プラットフォーム ガイド) を参照してください。

バックグラウンド チェック

加入したデバイスの順守状況を継続的に監視できます。AirWatch MDM Agent は、Android デバイスおよび、iOS 7 以降搭載のセルラー接続が可能な iOS デバイスのすべてにおいて、バックグラウンド チェックを定期的に実行し、侵害状態かどうかを調べます。

特に iOS 7 デバイスにおいては、AirWatch Agent による次の機能を利用できます。

  • App のバックグラウンド更新 - AirWatch では、AirWatch Agent が一定間隔でデバイス情報を収集/送信するように設定できます。このとき管理者は「間隔」パラメータをデバイスに送信することで、AirWatch Agent をどの程度の頻度で起動するかを指定します。この設定を有効にするには、AirWatch コンソールの デバイス > デバイス設定 > Apple > Apple iOS > Agent 設定 と進み、バックグラウンド アプリの更新 を選択して、目的に応じて 最小更新間隔Wi-Fi 接続時のみ送信可 を設定します。最小更新間隔 を指定すると、その時間内に一度、デバイスから MDM サーバに向けてデバイス情報の送信が試行されるようになります。
  • サイレント APNs - AirWatch は一定間隔で自動的に、サイレント APNs を介したバックグラウンド チェック要求を送信します。具体的には、AirWatch コンソールからデバイスに、デバイスの侵害状況を AirWatch サーバに送り返す要求の通知が送信されます。デバイス側では AirWatch Agent のプッシュ通知がオンになっている必要があります。
    また、管理者は手動でこの要求を送信することもできます。要求を送信するには、対象デバイスのデバイス詳細画面へ進み、その他のアクション > クエリ > AirWatch MDM Agent (下図) をクリックします。このコマンドは、適切なバージョンの AirWatch Agent がデバイスにインストールされている場合にのみ表示されます。

注:これら iOS 7 に特化したバックグラウンド チェック機能を利用するには、AirWatch Agent v4.9 以降が必要です。また、AirWatch Agent が非アクティブ (Inactive) 状態ではなく、アクティブ (Active)、サスペンド (Suspended)、バックグラウンド (Background) のいずれかの状態である必要があります。ユーザーが AirWatch Agent を明示的に終了した場合、次回 AirWatch Agent が起動されるまでバックグラウンド チェックは実行されません。

さらに、AirWatch SDK の侵害状態検出機能を使用することで、社内アプリでも上記と同様の条件でバックグラウンドでのジェイルブレーク検出を実現することができます。

アプリからのチェック

企業情報へのアクセスや AirWatch 機能を使用するタイミングを検出チェックポイントとして利用できます。具体的には、デバイスで AirWatch Content Locker、AirWatch Browser、AirWatch MDM Agent などが起動されたとき、検出システムが自動的に順守状況を検証します。これにより、貴社情報の保護をさらに強固なものにできます。

iOS や Android のラッピング アプリで侵害対策を有効にすることもできます。設定とポリシー の画面 (グループと設定 > すべての設定 > アプリ > 設定とポリシー > セキュリティ ポリシー) で、ラッピング アプリ用の他の設定とともにこの設定を有効にし、そのプロファイルを貴社のラッピング アプリに割り当てるだけです。詳細な手順などについては、『AirWatch App Wrapping Guide』(AirWatch App Wrapping ガイド) を参照してください。

iOS 用 SDK アプリの侵害検出を有効にすることもできます。iOS SDK 3.2 から、デバイスがオンラインかオフラインかにかかわらず、社内アプリで直接、デバイスの侵害状態を調べることができるようになりました。ただし、社内アプリでこの機能を使用できるのは、過去に一度でもビーコンの呼び出しに成功している場合に限られます。サンプル コードなどの詳細については、『AirWatch iOS SDK Guide』(AirWatch iOS SDK ガイド) を参照してください。

順守エンジン

侵害状態または非順守状態のデバイスが見つかると、AirWatch コンソールで設定されたデバイス ポリシーに従って、順守エンジンがこのデバイスに対してアクションを起こします。AirWatch は、デバイスの初期状態を検証するだけでなく、順守エンジンの間隔を設定することより任意の頻度でデバイスの状態を検証する柔軟性をも備えています。

企業アプリ組み込みの検出

AirWatch Agent をインストールする代わりに、AirWatch SDK を貴社の社内アプリに組み込んで利用することもできます。SDK には MDM の主要機能 (SDK プロファイルで指定可能な全項目) が含まれており、その中に定期的にスキャンを実施して順守状況を検証するジェイルブレーク/ルート化検出機能も含まれています。一般的に、デバイスにプッシュされた企業アプリは頻繁に実行されるので、デバイス状態スキャンもより高い頻度で実行され、結果として侵害状態のデバイスを見つけるまでの時間が短縮されます。

管理者は、侵害状態のデバイスにインストールされているアプリに対してどのようなアクションをとるかを、AirWatch コンソールで指定できます。たとえば、あるデバイスが侵害状態だと判明した場合、管理者は次のアクションを実行できます。

  • ユーザーに警告メッセージを送信する
  • ユーザーをデバイスからロックアウトする
  • アプリと企業データをワイプする
  • アクセスを制限する

 

侵害デバイスへの適用と監視

順守ポリシーを適用することで、iOS/Android デバイスの侵害状態を監視することができます。AirWatch コンソールには、管理者がシステムをセキュアで隙のない状態に保つ各種機能が備わっています。

注:Windows Phone デバイスでは侵害状態検出は必要ありません。これは、OS の UEFI とセキュア ブート プロセスでの保護により、既知のジェイルブレーク/ルート化状態がないためです。 

順守エンジン

順守エンジンは、ひとつのセキュリティ チェックポイントとして機能し、デバイスやユーザーに対し自動的にロックアウトや追加のアクションを実行します。管理者がそのデバイス用に設定した順守ルールに従って、デバイスが非順守状態かどうかを調べ、非順守状態であれば所定のアクションを起こします。これらのルールやアクションは、AirWatch コンソールで指定できます。

管理者に必要なのは、このようなルールやアクションの設定だけです。あとは順守エンジンがすべて行います。対応措置も自動的に実行されます。スキャンにより侵害状態のデバイスが見つかれば、システムが事前に設定された警告処理と追加のアクションを実行するので、管理者は検出された非順守状態デバイスに個別に対応する必要はありません。

これに対し、AirWatch コンソールから、順守プロトコルに則ったセルフ サービス処理を実行することもできます。管理者は、デバイスをワイプし、なぜそのデバイスが非順守なのかを記載した E メールまたは SMS メッセージをユーザーに送信できます。これにより、管理者がユーザーからの問い合わせに個別に対応する必要がなくなります。

デバイスの管理を順守エンジンに任せることで節約できる時間を使って、管理者は毎週/毎月の順守レポートに目を通し、違反を繰り返すユーザーを見つけることができます。

順守ルール「最終侵害状態スキャン」

順守ルール「最終侵害状態スキャン」では、AirWatch Agent によるデバイス スキャンが実行されていなければならない期間を管理者が設定できます。これにより、ある一定期間、AirWatch がデバイスから順守状態の通知を受け取らないと、何らかの予防措置のアクションを実行するようにも設定できます。

順守ルール「侵害状態」

順守ルール「侵害状態」により、管理者は侵害状態のデバイスに対するアクションを設定できます。

上記 2 つの順守ルールに対応して、次のアクションを適用できます。

  • 通知:SMS メッセージ、E メール、およびプッシュ通知を送信して、ユーザーに通知します。
  • アプリ:管理アプリの一部または全部をブロックまたは削除します。
  • コマンド:企業情報ワイプを実行したり、デバイスにチェックインを要求したりします。
  • プロファイル:全部、特定種類、または個別のプロファイルをブロックまたは削除します。

デバイス コントロール パネル

管理者はこの画面で加入済みデバイスの概要を確認できます。概要にはセキュリティ詳細が含まれており、個々のデバイスで侵害状態検出が実行済みかどうかがわかります。デバイスが侵害状態でなければ、緑のチェック マークが表示されます。

デバイスの順守状態の可視化

ダッシュボードには、組織グループ内の加入済みデバイスのうち、侵害状態のデバイスの比率がグラフ形式で表示されます。このグラフにより、管理者は侵害デバイスの概観を把握できます。また、それらのデバイスの追跡にも役立ちます。

定期的な順守レポートとオンデマンドの順守レポート

AirWatch コンソールには既定で 100 以上の標準レポートが用意されています。順守レポートもその一部で、一定間隔で自動的に実行されるものや、オンデマンドで生成するものがあります。この順守レポートにより、貴社が管理するデバイス全体からでも、特定の組織グループ内のデバイスからでも、非順守状態のデバイスを迅速に見つけることができます。たとえば、ブラックリスト アプリをインストールしているデバイス、パスコードの強度が不十分なデバイス、全般的なセキュリティ基準に違反しているデバイスなどを特定できます。順守レポートにより、システム内に存在する侵害状態や非順守状態のデバイスをひと目で把握できます。

 

まとめ

セキュアな MDM へのニーズはますます増大しています。そのニーズに応えるべく、AirWatch は侵害デバイスなどのセキュリティに対する脅威を検出し対抗するための、比類ないソリューションをお客様に提供します。この AirWatch 独自の重層的検出ソリューションは、すべてのデバイス プラットフォームで機能するように設計されており、さらに検出されたデバイスに対して必要なアクションがとれるという柔軟性も持ち合わせています。上記のような検出ソリューションの構成要素すべてにより、AirWatch は、貴社のビジネスをセキュアで調和がとれた状態に保つための、有効なソリューションとなっているのです。

Other Languages: English

免責事項:これは英文の記事「Compromised Device Overview」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

Have more questions? Submit a request

2 Comments

Article is closed for comments.