(57)【要約】【課題】データアクセスに起因するセキュリティインシデントの発生を抑制する。【解決手段】通信監視部１３において、アプリケーション１１に提供されるユーザデータ保存域１２のユーザデータに、エンドユーザが事前に指定した個人情報が含まれている場合、その個人情報が取得されない処理を実行する（個人情報をマスキングする、又は、ユーザデータをフィルタリングする）。【選択図】図１
2016206771.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションに提供されるデバイス内のユーザデータに対して、個人情報が取得されない処理を実行するデータ処理手段、
を有することを特徴とする通信監視装置。
【請求項２】
前記データ処理手段は、
前記ユーザデータに含まれる前記個人情報をマスキングすることを特徴とする請求項１に記載の通信監視装置。
【請求項３】
前記データ処理手段は、
前記個人情報が含まれる前記ユーザデータをフィルタリングすることを特徴とする請求項１又は２に記載の通信監視装置。
【請求項４】
前記アプリケーションによるＡＰＩコールをフックするＡＰＩフック手段と、
前記フックしたＡＰＩコールと同じＡＰＩをコールして実行するＡＰＩ実行手段と、を更に有し、
前記データ処理手段は、
前記実行した結果のユーザデータに対して前記個人情報を取得できない処理を実行することを特徴とする請求項１乃至３のいずれかに記載の通信監視装置。
【請求項５】
前記データ処理手段は、
センサ機器のデータをマスキング又はフィルタリングすることを特徴とする請求項１乃至４のいずれかに記載の通信監視装置。
【請求項６】
通信監視装置で行う通信監視方法において、
前記通信監視装置は、
アプリケーションに提供されるデバイス内のユーザデータに対して、個人情報が取得されない処理を実行するデータ処理ステップ、
を有することを特徴とする通信監視方法。
【請求項７】
請求項１乃至５のいずれかに記載の通信監視装置としてコンピュータを機能させることを特徴とする通信監視プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションに提供されるデバイス内のユーザデータを監視する技術に関する。
【背景技術】
【０００２】
汎用デバイスにインストールされたアプリケーションの中には、デバイス内の保存データにアクセスするアプリケーションや、その保存データを外部に送信するアプリケーションがある。しかし、個人情報を含むデータへのアクセスが発生すると、セキュリティインシデントに成り得る。
【０００３】
そのため、データアクセスに対するフィルタリング技術として、Ｗｉｎｄｏｗｓ（登録商標）などのオペレーティングシステムが備えるアクセス管理機能では、ファイルに対するアクセスの許可・拒否を選択する手段を提供している。また、Ａｎｄｒｏｉｄ（登録商標）を採用しているデバイスの場合、アプリケーションのインストール時に「アプリの権限」が表示され、使用する機能ブロック（例えば、「電話／通話」「連絡先」「画像／メディア」）を明示した上でエンドユーザに同意を要求する（非特許文献１）。それゆえ、アプリの権限に同意しないことにより、個人情報が含まれるデータへのアクセスを回避することができる。
【０００４】
また、アプリケーションが外部に向けて個人情報を含むデータを送信しようとする際のフィルタリング技術としては、例えばセキュリティソフトにより、特定のアプリケーションやプロトコルを監視し、外部送信中のデータにエンドユーザが事前に登録した個人情報が含まれているか否かを確認することが行われる（非特許文献２）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】“Android 4.3にアプリのアクセス権限を個別に無効化できる機能が追加”、juggly.cn、［online］、［平成27年4月3日検索］、＜URL: http://juggly.cn/archives/91264.html＞
【非特許文献２】“セキュリティソフトの個人情報の不正送信防止機能の比較”、the比較、［online］、［平成27年4月3日検索］、＜URL: http://thehikaku.net/security/08hikaku11.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、オペレーティングシステムが備えるアクセス管理機能の場合、アクセスの許可・拒否をファイル単位で決定するため、個人情報を除くデータを部分的にアプリケーションへ提供することができない。また、データ通信を監視する場合、アプリケーションと外部装置との間の通信経路が暗号化されてしまうとデータの内容を解析できず、個人情報が含まれているか否かを把握することができない。
【０００７】
本発明は、上記事情を鑑みてなされたものであり、データアクセスに起因するセキュリティインシデントの発生を抑制することを目的とする。
【課題を解決するための手段】
【０００８】
以上の課題を解決するため、請求項１に記載の通信監視装置は、アプリケーションに提供されるデバイス内のユーザデータに対して、個人情報が取得されない処理を実行するデータ処理手段、を有することを要旨とする。
【０００９】
請求項２に記載の通信監視装置は、請求項１に記載の通信監視装置において、前記データ処理手段は、前記ユーザデータに含まれる前記個人情報をマスキングすることを要旨とする。
【００１０】
請求項３に記載の通信監視装置は、請求項１又は２に記載の通信監視装置において、前記データ処理手段は、前記個人情報が含まれる前記ユーザデータをフィルタリングすることを要旨とする。
【００１１】
請求項４に記載の通信監視装置は、請求項１乃至３のいずれかに記載の通信監視装置において、前記アプリケーションによるＡＰＩコールをフックするＡＰＩフック手段と、前記フックしたＡＰＩコールと同じＡＰＩをコールして実行するＡＰＩ実行手段と、を更に有し、前記データ処理手段は、前記実行した結果のユーザデータに対して前記個人情報を取得できない処理を実行することを要旨とする。
【００１２】
請求項５に記載の通信監視装置は、請求項１乃至４のいずれかに記載の通信監視装置において、前記データ処理手段は、センサ機器のデータをマスキング又はフィルタリングすることを要旨とする。
【００１３】
請求項６に記載の通信監視方法は、通信監視装置で行う通信監視方法において、前記通信監視装置は、アプリケーションに提供されるデバイス内のユーザデータに対して、個人情報が取得されない処理を実行するデータ処理ステップ、を有することを要旨とする。
【００１４】
請求項７に記載の通信監視プログラムは、請求項１乃至５のいずれかに記載の通信監視装置としてコンピュータを機能させることを要旨とする。
【発明の効果】
【００１５】
本発明によれば、データアクセスに起因するセキュリティインシデントの発生を抑制できる。
【図面の簡単な説明】
【００１６】
【図１】本発明のアーキテクチャを示す図である。
【図２】実施例１に係るデバイスの機能ブロック構成を示す図である。
【図３】通信監視部の処理フローを示す図である。
【図４】実施例１の監査ポリシの例を示す図である。
【図５】実施例２に係るデバイスシステムの機能ブロック構成を示す図である。
【図６】デバイスシステムの処理フローを示す図である。
【図７】実施例２の監査ポリシの例を示す図である。
【発明を実施するための形態】
【００１７】
上記の課題を解決するため、本発明は図１のアーキテクチャで構成される。このアーキテクチャは、デバイス１と、アプリケーション１１と、ユーザデータ保存域１２と、通信監視部１３と、の４つの要素で構成される。
【００１８】
デバイス１は、オペレーティングシステムを搭載し、その上でソフトウェアプログラムが動作する汎用の情報処理端末である。例えば、パーソナルコンピュータ、サーバ、スマートフォン端末、タブレット端末である。
【００１９】
アプリケーション１１は、所定のサービスに合わせて任意の振る舞いをするソフトウェアプログラムである。例えば、サービスプロバイダ、アプリケーション開発者、ソフトウェアコミュニティにより提供される。図１では、通信監視部１３とユーザデータ保存域１２とが共に同一のパーソナルデバイス上に存在しているが、必ずしも同一のパーソナルデバイス上に存在する必要は無く、ネットワークを通じて別のデバイスに存在させてもよい。
【００２０】
ユーザデータ保存域１２は、ユーザが所有するデータが保存されているメモリ上の領域である。ユーザデータには、例えばスマートフォン端末であれば、アドレス帳、メールデータ、インターネット閲覧履歴、電話の発着信履歴、静止画、動画、音楽といったメディアデータである。ユーザが任意で蓄積したデータに限らず、デバイスやシステム、アプリケーション自身が生成するデータ、更には、ＧＰＳや加速度センサなどのセンサ類が生成する個人情報に類似したセンサ情報（例えば、位置情報、加速度情報、心拍、血圧）でもよい。
【００２１】
通信監視部１３は、ユーザデータを監査し、必要に応じてマスキングやフィルタリングを行う。アプリケーション１１がユーザデータ保存域１２からユーザデータを取得する場合、本通信監視部１３を必ず経由する。
【００２２】
全体の処理フローとしては、デバイス１上で動作するアプリケーション１１が個人情報を含むユーザデータをユーザデータ保存域１２から取得しようとした際、通信監視部１３は、そのユーザデータを監査し、必要に応じてマスキング又はフィルタリングの処理を施す、という流れになる。
【００２３】
なお、マスキングとは、ユーザデータの一部を加工し、個人を識別できない状態にしてアプリケーション１１へ渡す処理である。例えば、メール本文に記載された電話番号やパスワード文字列をアスタリスクへと変換する、動画ファイルや画像ファイルに描画された個人の顔に目線を隠す黒塗りを入れる、動画ファイルや音声ファイルに含まれる個人の音声を加工する、といった処理が該当する。また、フィルタリングとは、そのユーザデータをアプリケーション１１へ渡すことなく、通信監視部１３で破棄する処理である。フィルタリングが実行された場合であってもオリジナルのユーザデータが消去されることは無い。
【００２４】
以下、本発明を実施する実施例について図面を用いて説明する。
【実施例１】
【００２５】
実施例１では、アプリケーション１１とユーザデータ保存域１２が同一のデバイス１上に存在する場合について説明する。
【００２６】
図２は、本実施例に係るデバイス１の機能ブロック構成を示す図である。本実施例での通信監視部１３は、ＡＰＩフック部１３１と、データ処理部１３２と、処理エンジン部１３３と、ＡＰＩ実行部１３４と、設定入力部１３５と、設定保持部１３６と、を備えて構成される。
【００２７】
ＡＰＩフック部１３１は、アプリケーション１１によるＡＰＩのコールを常に監視し、コールされたＡＰＩをフック（捕捉）する。フックされたＡＰＩはデータ処理部１３２を経てＡＰＩ実行部１３４で実行され、その実行結果はコール元のアプリケーション１１へ返却される。なお、ＡＰＩとは、Application Programming Interfaceの略称であり、デバイス１のオペレーティングシステムやＳＤＫ（Software Development Kit）により提供される。
【００２８】
データ処理部１３２は、ＡＰＩフック部１３１から処理を受けた際は何も行わず、その処理をＡＰＩ実行部１３４へ渡す。一方、ＡＰＩ実行部１３４の実行結果をＡＰＩフック部１３１へ返却する際は、その実行結果に対して監査を行い、マスキング又はフィルタリングを行う。なお、マスキングやフィルタリングを行うか否かの判断は処理エンジン部１３３で行われる。監査ポリシは設定保持部１３６に保存されており、監査時にはその監査ポリシに該当するかを判定する。
【００２９】
処理エンジン部１３３は、データ処理部１３２により呼び出され、ＡＰＩ実行部１３４での実行結果に含まれるデータに対してマスキングやフィルタリングを行うか否かを判断する。複数の処理エンジン部１３３で構成されていてもよい。処理エンジン部１３３はデータ処理部１３２に対して独立していてプラガブルであり、データ処理部１３２は実施したい処理に対して処理エンジン部１３３を任意に選択することができる。処理内容を変更したい場合、処理エンジン部１３３の追加や入れ替えによって実現する。
【００３０】
ＡＰＩ実行部１３４は、ＡＰＩフック部１３１がフックしたＡＰＩ（以下、元のＡＰＩ）と同じＡＰＩをコールして実行し、その実行結果をデータ処理部１３２へ返却する。なお、元のＡＰＩと同じＡＰＩをコールする理由は、ＡＰＩの実行結果はＡＰＩのコール元にしか返されないためである。
【００３１】
設定入力部１３５は、データ処理部１３２で用いる監査ポリシの入力や編集が可能なユーザインタフェースを持つ。エンドユーザは、そのユーザインタフェースを通じて監査ポリシを入力する。
【００３２】
設定保持部１３６は、設定入力部１３５を通じて入力された監査ポリシを蓄積する。蓄積された監査ポリシは、実行結果の監査時にデータ処理部１３２により参照される。
【００３３】
次に、通信監視部１３の動作について説明する。図３は、通信監視部１３の処理フローを示す図である。ここでは、あるアプリケーションＡが、ユーザデータ保存域１２に保存されているユーザデータＵへアクセスする状況を考える。ユーザデータＵは映像形式のファイルであり、エンドユーザはユーザデータＵに含まれる人物の顔を識別できないように扱う必要があるとする。
【００３４】
まず、ステップＳ１０１において、設定入力部１３５は、エンドユーザによる監査ポリシの入力を受け付け、設定保持部１３６に予め蓄積しておく。監査ポリシには、例えば、「呼び出し元アプリケーション」、「対象とするユーザデータの種類」、「監査条件」、「監査内容」が含まれる。具体的には、図４に示すように、「呼び出し元アプリケーション」は“アプリケーションＡ”、「対象とするユーザデータの種類」は“メディアファイル（画像形式又は映像形式のファイル）”、「監査条件」は“人物の顔を含む”、「監査内容」は“人物の顔を特定できないようマスキング”、という“監査ポリシ１”の監査ポリシが設定される。
【００３５】
その後、アプリケーションＡが独自の契機でユーザデータＵへのアクセス用のＡＰＩ（元のＡＰＩ）をコールすると、ステップＳ１０２において、ＡＰＩフック部１３１は、その元のＡＰＩコールをフックし、データ処理部１３２を介してＡＰＩ実行部１３４へと受け渡す。データ処理部１３２では何も処理を行わない。
【００３６】
次に、ステップＳ１０３において、ＡＰＩ実行部１３４は、受け取った元のＡＰＩと同じＡＰＩをコールし、コールしたＡＰＩの実行結果であるユーザデータＵをデータ処理部１３２へと受け渡す。
【００３７】
次に、ステップＳ１０４において、データ処理部１３２は、ＡＰＩ実行部１３４から実行結果のユーザデータＵ（＝映像形式のファイル）を受け取ると、設定保持部１３６を参照し、合致する監査ポリシを呼び出す。この例では、「呼び出し元アプリケーション」が“アプリケーションＡ”であり、「実行結果のユーザデータの種類」が“メディアファイル”であるため、“監査ポリシ１”が適用される。そして、呼び出した“監査ポリシ１”の「監査条件」に従い、処理エンジン部１３３にてユーザデータＵの中に人物の顔を含むシーンが存在するかを判定する。
【００３８】
次に、ステップＳ１０５において、該当するシーンがあった場合、データ処理部１３２は、“監査ポリシ１”の「監査内容」に基づきマスキング処理を適用する。一方、ユーザデータＵの中に人物の顔を含むシーンがない場合は、マスキング処理を適用しない。
【００３９】
最後に、ステップＳ１０６において、データ処理部１３２は、マスキング処理を適用し終えたユーザデータＵ’をＡＰＩフック部１３１を通じて呼び出し元のアプリケーションＡへと返却する。
【００４０】
なお、アプリケーションＡからすると自身のＡＰＩコールに対して実行結果のユーザデータＵ’を取得したにすぎないため、上述した通信監視部１３の処理動作により、アプリケーションＡにおいて、自身で行ったＡＰＩコールがフックされたことや、取得したユーザデータＵ’がマスキングされていることを把握することはない。よって、通信監視部１３の存在がアプリケーションＡの動作に影響を与えることはない。
【００４１】
更に、ユーザデータ保存域１２がＧＰＳや加速度計のようなセンサであった場合を考える。この場合、ユーザデータ保存域１２へのアクセス＝センサへのアクセスとなり、ユーザデータを参照するにはセンサへアクセスしてセンサ値を取得することとなる。センサ類に対して設定可能な監査ポリシの「監査内容」としては、例えば“アクセス拒否”が考えられる。アクセス拒否とは、アプリケーション１１からセンサへのアクセスを通信監視部１３にて破棄・遮断（＝フィルタリング）することである。これにより、特定のアプリケーション１１がセンサ類にアクセスしてセンサ値を取得することを防止できる。オプションとして、一定時間又は一定回数のみ一時的にアクセスを許可する設定や、センサ値が特定範囲内の場合のみアクセスを許可する設定や、特定種のセンタ値の場合のみアクセスを許可するといった設定も可能である。
【実施例２】
【００４２】
実施例２では、アプリケーション１１とユーザデータ保存域１２がそれぞれ異なるデバイス上に存在し、そのデバイス同士がネットワークで接続されている場合について説明する。
【００４３】
図５は、本実施例に係るデバイスシステム３００の機能ブロック構成を示す図である。このデバイスシステム３００は、第１のデバイス１ａと、第２のデバイス１ｂと、を備えて構成される。
【００４４】
第１のデバイス１ａはアプリケーション１１を備え、第２のデバイス１ｂはユーザデータ保存域１２と通信監視部１３を備える。第１のデバイス１ａと第２のデバイス１ｂは外部ネットワークＮを通じて通信可能であり、その通信を行うために第１の外部接続部１４ａと第２の外部接続部１４ｂが第１のデバイス１ａと第２のデバイス１ｂにそれぞれ具備されている。なお、実施例１と同名の機能部については、その処理内容も実施例１と同様であるため詳細は省略する。通信監視部１３は、第１のデバイス１に存在してもよい。
【００４５】
第１の外部接続部１４ａと第２の外部接続部１４ｂは、いずれも、外部ネットワークＮを通じて一方のデバイスを他方のデバイスへ接続し、通信を確立する。また、特定のプロトコルやポート番号、通信元・通信先アドレスなどの指定により、処理を他の機能部へ振り分ける。
【００４６】
次に、デバイスシステム３００の動作について説明する。図６は、デバイスシステム３００の処理フローを示す図である。ここでは、第１のデバイス１ａのアプリケーションＡが、第２のデバイス１ｂのユーザデータ保存域１２のユーザデータＵへアクセスする状況を考える。ユーザデータＵは映像形式のファイルであり、エンドユーザはユーザデータＵに含まれる人物の顔を識別できないように扱う必要があるとする。
【００４７】
まず、ステップＳ２０１において、設定入力部１３５は、エンドユーザによる監査ポリシの入力を受け付け、設定保持部１３６に予め蓄積しておく。これは実施例１のステップＳ１０１と同じである。ただし、監査ポリシには、アプリケーションが存在しているデバイスの識別子（例えば、ＭＡＣアドレスやＩＰアドレス）を更に含むものとする。具体的には、図７に示すように、「デバイス識別子」に“第１のデバイス”が設定された“監査ポリシ１”の監査ポリシが設定される。
【００４８】
次に、ステップＳ２０２において、第２の外部接続部１４ｂは、ユーザからの入力を受け付け、ユーザデータ保存域１２へアクセスする通信を通信監視部１３を経由するように設定する。ユーザデータ保存域１２へアクセスする際に用いるプロトコル及びポート番号は既知であり、そのプロトコルをＰｒ１、そのポート番号をＰｏ１とする。
【００４９】
次に、ステップＳ２０３において、第１のデバイス１ａのアプリケーションＡは、独自の契機で第１の外部接続部１４ａ、外部ネットワークＮ、第２の外部接続部１４ｂを順に通じて第２のデバイス２ａのユーザデータＵへのアクセスを試みる。
【００５０】
次に、ステップＳ２０４おいて、第２の外部接続部１４ｂは、その通信プロトコルがＰｒ１であり、かつ、そのポート番号がＰｏ１であることから、ユーザデータ保存域１２へアクセスさせず、通信監視部１３を経由させ処理を継続させる。
【００５１】
その後、ステップＳ２０５おいて、通信監視部１３は、実施例１で説明したステップＳ１０３〜ステップＳ１０６と同様の処理を実行する。すなわち、データ処理部１３２はそのまま処理をＡＰＩ実行部１３４へと移し、ＡＰＩ実行部１３４はユーザデータＵをユーザデータ保存域１２から取得してデータ処理部１３２へ返却する。そして、ユーザデータＵを受け取ったデータ処理部１３２は、設定保持部１３６を参照してユーザデータＵに対して合致する監査ポリシ１を適用し、人物の顔をマスキングしたユーザデータＵ’を生成して第２の外部接続部１４ｂへと返却する。
【００５２】
最後に、ステップＳ２０６おいて、第２の外部接続部１４ｂは、返却されたユーザデータＵ’を外部ネットワークＮを介して第１のデバイス１ａに送信する。その後、第１の外部接続部１４ａは、第２のデバイス１ｂからのユーザデータＵ’を受信し、アプリケーションＡへと渡す。
【００５３】
以上より、実施例１，２によれば、通信監視部１３において、アプリケーション１１に提供されるユーザデータ保存域１２のユーザデータに、エンドユーザが事前に指定した個人情報が含まれている場合、その個人情報が取得されない処理を実行する（個人情報をマスキングする、又は、ユーザデータをフィルタリングする）ので、個人情報をアプリケーション１１に渡さないことが可能となり、アプリケーション１１による個人情報の不用意な流出・漏洩リスクを低減可能となる。その結果、データアクセスに起因するセキュリティインシデントの発生を抑制することができる。特に個人情報をマスキングする場合、個人情報以外はアプリケーション１１に渡されるので、ユーザの持つ価値あるユーザデータを安全かつ有効に活用することができる。
【００５４】
最後に、実施例１，２で説明した通信監視部１３は、ＣＰＵ等の演算機能やメモリ等の記憶機能を備えたコンピュータで実現できる。また、通信監視部１３としてコンピュータを機能させるための通信監視プログラムや該通信監視プログラムの記憶媒体を作成することも可能である。
【符号の説明】
【００５５】
１…デバイス
１ａ…第１のデバイス
１ｂ…第２のデバイス
１１…アプリケーション
１２…ユーザデータ保存域
１３…通信監視部（通信監視装置）
１４ａ…第１の外部接続部
１４ｂ…第２の外部接続部
１３１…ＡＰＩフック部（ＡＰＩフック手段）
１３２…データ処理部（データ処理手段）
１３３…処理エンジン部
１３４…ＡＰＩ実行部（ＡＰＩ実行手段）
１３５…設定入力部
１３６…設定保持部
３００…デバイスシステム
Ｓ１０１〜Ｓ１０６、Ｓ２０１〜Ｓ２０６…ステップ
【図１】
2016206771.tif 000003
【図２】
2016206771.tif 000004
【図３】
2016206771.tif 000005
【図４】
2016206771.tif 000006
【図５】
2016206771.tif 000007
【図６】
2016206771.tif 000008
【図７】
2016206771.tif 000009