アクセス制御システム、アクセス制御装置、及び制御方法
【課題】アプリケーションからアクセス先へのデータのアクセスを制御すること。
【解決手段】アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報をＡＰＩから抽出する監視部１１０と、監視部１１０がＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するアクセス制御部１２０とを備える。
【解決手段】アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報をＡＰＩから抽出する監視部１１０と、監視部１１０がＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するアクセス制御部１２０とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセス制御システム、アクセス制御装置、及び制御方法に関する。特に、本発明は、アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御システム、アクセス制御装置、並びに、当該アクセス制御装置を制御する制御方法に関する。
【背景技術】
【０００２】
アプリケーション配信サービスは、特に、携帯電話やスマートフォン等の携帯情報端末向けのアプリケーションを配信するマーケットとして拡大している。携帯情報端末のユーザは、通信事業者や端末メーカが提供するマーケットや個人サイト等から、好みのアプリケーションを携帯情報端末へダウンロードすることによって、携帯情報端末の機能を追加したり、カスタマイズしたりすることができる。
【０００３】
ところで、アプリケーションは、携帯情報端末内の機能を利用して動作することがある。しかしながら、携帯情報端末内の機能は、不用意に利用されてしまうと、セキュリティ上の脅威となる虞がある。例えば、悪意のあるアプリケーションは、携帯情報端末内のファイルを削除してしまうこともある。
【０００４】
アプリケーションの証明書を用いるアクセス制限方法は、上述したような問題に対する対策の一つとして利用されている。アプリケーションダウンロード時にアプリケーションに付加された証明書を検証することで、アプリケーションを信頼できるもの／できないものに分け、使用可能な端末内機能を限定するという方法である。悪意のあるアプリケーションがダウンロードされても限定された機能にしかアクセスできないため、システム上の重要なトラブルは防げる。以降、機能へのアクセス権をパーミッションと呼ぶ。
【０００５】
ただし、上記方法では、アプリケーション間でデータ送受信を行ったり、サーバにデータ送信を行う場合に問題が発生する。例えば、信頼できるアプリケーション（パーミッションを持つアプリケーション）のみが取得できるデータを、信頼できないアプリケーション（パーミッションを持たないアプリケーション）に対して送信してしまうケースも考えられる。これを防ぐためには、通信を監視する仕組みが必要である。
【０００６】
特許文献１に、通信を監視するためのシステムが記載されている。特許文献１では、クライアント−サーバ間の通信を解析し、情報の漏洩を検出する機能を持つ。クライアント−サーバ間の通信を複合器又はデコンプレッサを適用し、スキャナを用いてデータを解析することで、予め登録された顧客リスト等のデジタル資産や禁止キーワードに対応する情報の漏洩を防ぐ。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−２１１７０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１に記載の高性能のネットワーク内容解析プラットフォームは、予め定められたデータの漏洩を防ぐことができる。しかしながら、特許文献１に記載の高性能のネットワーク内容解析プラットフォームは、状態によって変化するようなデータに対応することができない。例えば、携帯情報端末の位置情報は、携帯情報端末の位置によって変化する。そのため、携帯情報端末の位置情報は、アプリケーションから他のアプリケーションへ送信される場合、検出することができない。全ての位置情報を禁止情報として登録するのは現実的ではない。これを解決するためには、情報の送信元が保持する情報を考慮した監視の仕組みが必要になる。
【０００９】
また、上記解決策として、先述した証明書によるアクセス制限の仕組みにより、アプリケーション間通信を禁止することも考えられる。しかし、アプリケーション間通信を全て禁止することになり、利便性が損なわれる。このため、通信内容によって制限するような仕組みが必要になる。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明の第１の形態によると、アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御システムであって、アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報をＡＰＩから抽出する監視部と、監視部がＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するアクセス制御部とを備える。
【００１１】
また、本発明の第２の形態によると、アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御装置であって、アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報をＡＰＩから抽出する監視部と、監視部がＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するアクセス制御部とを備える。
【００１２】
また、本発明の第３の形態によると、アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御装置を制御する制御方法であって、アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報をＡＰＩから抽出する監視段階と、監視段階においてＡＰＩから抽出された情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するアクセス制御段階とを備える。
【００１３】
なおまた、上記のように発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となり得る。
【発明の効果】
【００１４】
以上の説明から明らかなように、この発明においては、アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報を前記ＡＰＩから抽出し、抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するようにしたので、パーミッションを持つアプリケーションからパーミッションを持たないアプリケーションへのデータ漏洩を防ぐことができる。
【００１５】
また、この発明においては、アプリケーションからアクセス先への通信そのものを許可しない訳ではなく、通信内容に応じてアクセス制御を行うため利便性を損なう虞がない。
【図面の簡単な説明】
【００１６】
【図１】一実施形態に係る情報機器１００のブロック構成の一例を示す図である。
【図２】アプリケーションＡ、監視部１１０、アクセス制御部１２０、及びデータベース作成部１３０の動作シーケンスの一例を示す図である。
【図３】パーミッションリスト１４０に記憶されているデータの一例を示す図である。
【図４】アプリケーション情報リスト１５０に記憶されているデータの一例を示す図である。
【図５】アクセス情報データベース１６０に記憶されるデータの一例を示す図である。
【図６】アプリケーションＡ、監視部１１０、及びアクセス制御部１２０の動作シーケンスの一例を示す図である。
【図７】監視部１１０が抽出するデータの一例を示す図である。
【図８】アクセス情報データベース１６０に記憶されるデータの一例を示す図である。
【図９】送信先リスト１７０に記憶されているデータの一例を示す図である。
【図１０】パーミッションリスト１４０に記憶されているデータの一例を示す図である。
【図１１】アプリケーション情報リスト１５０に記憶されているデータの一例を示す図である。
【図１２】アクセス情報データベース１６０に記憶されるデータの一例を示す図である。
【発明を実施するための形態】
【００１７】
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は、特許請求の範囲にかかる発明を限定するものではなく、また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１８】
図１は、一実施形態に係る情報機器１００のブロック構成の一例を示す。情報機器１００は、アプリケーションから他のアプリケーションへのデータのアクセスを制御する。なおまた、情報機器１００は、この発明における「アクセス制御装置」の一例であってよい。また、他のアプリケーションは、この発明における「アクセス先」の一例であってよい。
【００１９】
携帯機器１００は、監視部１１０、アクセス制御部１２０、データベース作成部１３０、パーミッションリスト１４０、アプリケーション情報リスト１５０、及びアクセス情報データベース１６０を備える。以下に、各構成要素の機能及び動作を説明する。
【００２０】
監視部１１０は、アプリケーションによるパーミッション対象ＡＰＩの発行を監視する。そして、監視部１１０は、パーミッション対象ＡＰＩの発行を検知すると、発行元アプリケーションＩＤと、ＡＰＩ情報とをアクセス制御部１２０に渡す。また、監視部１１０は、アプリケーション間の通信や外部との通信ＡＰＩも監視する。そして、監視部１１０は、ＡＰＩの発行を検知すると、発行元アプリケーションＩＤと、送信先アプリケーションＩＤと、送信するデータとをアクセス制御部１２０に渡す。
【００２１】
アクセス制御部１２０は、パーミッションリスト１４０とアプリケーション情報リスト１５０とを参照して、ＡＰＩの実行可否を判定する。ＡＰＩ発行元のアプリケーションがパーミッションを保持していない場合はＡＰＩの実行を不可と判定する。これに加え、アクセス制御部１２０は、アプリケーション情報リスト１５０とアクセス情報データベース１６０を参照して、アプリケーション間の通信や外部との通信ＡＰＩの実行可否の判定も行う。送信先のアプリケーションが送信データに対応するパーミッションを保持していない場合は通信不可と判定する。
【００２２】
データベース作成部１３０は、パーミッション対象ＡＰＩを解析し、発行元アプリケーションとパーミッション対象ＡＰＩによって取得したデータを管理するため、アクセス情報データベース１６０の操作を行う。
【００２３】
パーミッションリスト１４０は、パーミッションと、そのパーミッションに紐付けられるＡＰＩとを記憶している。
【００２４】
アプリケーション情報リスト１５０は、アプリケーションと、そのアプリケーションが利用可能なパーミッションとを記憶している。
【００２５】
アクセス情報データベース１６０は、アプリケーションによって発行されたパーミッション対象ＡＰＩと取得したデータの履歴を蓄積する。
【００２６】
図２は、アプリケーションＡ、監視部１１０、アクセス制御部１２０、及びデータベース作成部１３０の動作シーケンスの一例を示す。図３は、パーミッションリスト１４０に記憶されているデータの一例を示す。図４は、アプリケーション情報リスト１５０に記憶されているデータの一例を示す。図５は、アクセス情報データベース１６０に記憶されるデータの一例を示す。以下、アクセス情報データベース作成処理について説明する。
【００２７】
アプリケーション（アプリケーションＡ）がパーミッション対象であるＡＰＩ１の呼出しを行ったとする（Ｓ１０１）。
【００２８】
監視部１１０は、ＡＰＩ１が呼ばれたことを検知し、アクセス制御部１２０にアクセス制御処理を依頼する（Ｓ１０２）。この際、ＡＰＩ発行元のアプリケーションＩＤ（アプリケーションＡ）とＡＰＩ名（ＡＰＩ１）を通知する。
【００２９】
アクセス制御部１２０は、監視部１１０から渡された情報をもとにアクセス可否判定を行う（Ｓ１０３）。より具体的には、まず、ＡＰＩ名をもとにパーミッションリスト１４０を参照することで、発行されたＡＰＩに対応するパーミッションを取得する。パーミッションリスト１４０の例を図３に示す。ここでは、発行されたＡＰＩ１に対応するパーミッションは、パーミッション１であることがわかる。次に、アクセス制御部１２０は、パーミッション情報をもとにアプリケーション情報リスト１５０を参照することで、発行元アプリケーションがそのパーミッションを保持するか否かを判定する。アプリケーション情報リスト１５０の例を図４に示す。ここでは、アプリケーションＡは、パーミッション１を利用可能であることがわかる。このため、アクセス可と判定される。そして、アクセス制御部１２０は、その判定結果を監視部１１０へ通知する（Ｓ１０４）。
【００３０】
アクセス不可の場合、監視部１１０は、アプリケーションに対し、その旨を通知する（Ｓ１０５）。アクセス可の場合はＡＰＩ１が実行され、監視部１１０は、ＡＰＩ１によって得られたデータ（データ１）を取得する（Ｓ１０６）。次に、監視部１１０は、データベース作成部１３０にデータベース作成依頼を行う（Ｓ１０７）。この際、発行元のアプリケーションＩＤ（アプリケーションＡ）と、ＡＰＩ１によって取得したデータ（データ１）を通知する。
【００３１】
データベース作成部１３０は、監視部１１０から渡された情報をもとにアクセス情報データベースを作成する（Ｓ１０８）。アクセス情報データベース１６０の例を図５に示す。図５のように、アプリケーションＡが使用したパーミッションと取得したデータの履歴が保存される。以上が、アクセス情報データベース作成処理である。
【００３２】
図６は、アプリケーションＡ、監視部１１０、及びアクセス制御部１２０の動作シーケンスの一例を示す。図７は、監視部１１０が抽出するデータの一例を示す。図８は、アクセス情報データベース１６０に記憶されるデータの一例を示す。以下、アクセス制御処理について説明する。
【００３３】
まず、アプリケーション（アプリケーションＡ）は他のアプリケーション（アプリケーションＢ）とアプリケーション間通信を行うためＡＰＩの呼出しを行う（Ｓ２０１）。
【００３４】
監視部１１０は、ＡＰＩの呼出しを検知し、ＡＰＩの解析を行う（Ｓ２０２）。ここでは、図７のように、送信元アプリケーションＩＤと通信先アプリケーションＩＤ、送信するデータを抽出する。次に、抽出したデータを付加し、アクセス制御部１２０にアクセス制御処理を依頼する（Ｓ２０３）。
【００３５】
アクセス制御部１２０は、監視部１１０から渡された情報をもとにアクセス可否判定を行う（Ｓ２０４）。より具体的には、まず、アクセス情報データベース１６０を参照することで、送信元アプリケーションが送信するデータを過去に取得しているか否かを判定し、取得している場合はそのパーミッションを取得する。ここでは、図５に示したようにアプリケーションＡは、データ１を取得しているため、そのパーミッションであるパーミッション１を取得する。次に、アクセス制御部１２０は、アプリケーション情報リスト１５０を参照することで、送信先アプリケーションであるアプリケーションＢがパーミッション１を使用可能か否かを判定する。ここでは、図４に示すように、アプリケーションＢはパーミッション１を保持しないため、使用できないと判定される。よって、アプリケーションＡによるアプリケーション間通信ＡＰＩは不可と判定される。そして、アクセス制御部１２０は、判定結果を監視部１１０へ通知する（Ｓ２０５）。
【００３６】
アクセス不可の場合、監視部１１０は、アプリケーションに対し、その旨を通知する（Ｓ２０６）。
【００３７】
以上が、アクセス制御処理である。なおまた、Ｓ２０４でアクセス可と判定された場合は、アプリケーション間通信ＡＰＩが実行される。その後、図２で説明したアクセス情報データベース作成処理へと遷移する。すなわち、アプリケーションＢは、パーミッション１を使用し、データ１を取得したものとされる。これを図８に示す。
【００３８】
以上説明したように、本実施の形態によると、パーミッション対象のＡＰＩを監視することで、そのＡＰＩによって得られたデータを蓄積することができる。これにより、通信時に通信内容を解析することで、以前取得したデータが含まれているかがわかる。このため、そのデータに対応するパーミッションを送信先が保持しているかによって通信の可否を判定することができる。結果、パーミッションを持たないアプリケーションへの情報漏えいを防ぐことができる。
【００３９】
図９は、送信先リスト１７０に記憶されているデータの一例を示す。以上の説明においては、監視する通信をアプリケーション間通信としていたが、これに限らない。すなわち、インターネット上のサーバに通信する際にも適用できる。例えば、図９に示す送信先リスト１７０を追加し、アクセス制御部１２０が参照することで実現できる。送信先リスト１７０には、送信先サーバＩＤとそのサーバに送信可能なパーミッション情報が記載されている。サーバＩＤは、例えばＵＲＬである。
【００４０】
この際の処理の流れは、上記の実施の形態におけるアクセス制御処理と同様であるが、アクセス制御部１２０は、サーバへの通信である場合は、アプリケーション情報リスト１５０ではなく、上記送信先リスト１７０を参照することで、送信先サーバがパーミッションを保持しているか否かを判定し、通信可否を判定する。
【００４１】
また、図１のパーミッションリスト１４０は、予め用意されているものとしていたがこれに限らない。すなわち、ダウンローダによってアプリケーションが検証され、アプリケーションとそのアプリケーションが使用可能なパーミッションのリストが追加されてもよい。この場合、情報機器１００に予め登録されているアプリケーションだけでなく、アプリケーション配信サービスからダウンロードするアプリケーションに対しても本発明を適用することができる。すなわち、情報機器１００上で動作する全てのアプリケーションが対象である。
【００４２】
また、パーミッションリスト１４０とアプリケーション情報リスト１５０を別々にしていたが、これに限らない。アプリケーションＩＤ、パーミッション、ＡＰＩ名を保持する１つのリストとして管理してもよい。アクセス制御部１２０は、図２のＳ２０３においてアクセス可否を判定する際、アプリケーションＩＤとＡＰＩ名から、ＡＰＩ発行元アプリケーションがパーミッションを保持するか否かを判断することができる。
【００４３】
また、図６のＳ６０４にて、送信するデータを過去に取得しているか否かを判定する際、完全一致を前提としていたが、これに限らない。すなわち、例えば、送信するデータが、「取得したデータは、データ１である」という内容であった場合、送信元アプリケーションが以前取得した「データ１」が含まれていると判断する。
【００４４】
図１０は、パーミッションリスト１４０に記憶されているデータの一例を示す。図１１は、アプリケーション情報リスト１５０に記憶されているデータの一例を示す。図１２は、アクセス情報データベース１６０に記憶されるデータの一例を示す。次に、具体的な実施例を用いて本発明を実施するための最良の形態の動作を説明する。本実施例では、携帯端末において、位置情報を取得するパーミッションを保持する地図アプリケーションが、パーミッションを持たないグルメアプリケーションにアプリケーション間通信で送信する例を説明する。
【００４５】
まず、アクセス情報データベース作成処理を説明する。地図アプリケーションは、実行中に位置情報を取得するためにＡＰＩ（ｇｅｔＬｏｃａｔｉｏｎ（））を呼ぶ。ｇｅｔＬｏｃａｔｉｏｎ（）内には監視部１１０が（別のＡＰＩ等で）組み込まれており、地図アプリケーションがｇｅｔＬｏｃａｔｉｏｎ（）を呼んだことを検知できる。この際、監視部１１０は、地図アプリケーションのＩＤ（ｍａｐ＿ａｐｐ）とＡＰＩ名（ｇｅｔＬｏｃａｔｉｏｎ）をアクセス制御部１２０に通知する。アクセス制御部１２０は、図１０のパーミッションリスト１４０と図１１のアプリケーション情報リスト１５０を参照することで、図２のＳ２０３で説明したアクセス可否判定を行う。地図アプリケーションは位置情報を取得するパーミッションを保持するため、アクセス可と判定される。アクセス可と判定されると、制御が監視部１１０に遷移し、監視部１１０はｇｅｔＬｏｃａｔｉｏｎ（）によって取得した位置情報（緯度・経度情報）を取得する。次に、取得した位置情報、パーミッション、呼出し元アプリケーションＩＤをもとにアクセス情報データベース１６０を作成する。すでに情報が格納されている場合は、追加していくことで履歴を作成する。作成後のアクセス情報データベース１６０を図１２に示す。
【００４６】
次に、アクセス制御処理を説明する。地図アプリケーションは、アプリケーション間通信ＡＰＩ（ｓｅｎｄＤａｔａ（））を呼ぶ。ｓｅｎｄＤａｔａ（）のフォーマットは第一引数に送信先アプリケーションＩＤ、第二引数にデータを指定することとする（ｓｅｎｄＤａｔａ（”ｇｏｕｒｍｅｔ＿ａｐｐ”， ”３５．４５， １３５．４５”））。ｓｅｎｄＤａｔａ（）内には監視部１１０が組み込まれており、地図アプリケーションがｓｅｎｄＤａｔａ（）を呼んだことを検知できる。この際、監視部１１０は、送信元アプリケーションＩＤ（ｍａｐ＿ａｐｐ）、送信先アプリケーションＩＤ（ｇｏｕｒｍｅｔ＿ａｐｐ）、送信データ（３５．４５， １３５．４５）をアクセス制御部１２０に通知する。アクセス制御部１２０は、送信データをキーにして、アクセス情報データベース１６０（図１２）を参照することで、送信するデータがＰＥＲＭ＿ＬＯＣＡＴＩＯＮに関連する情報であり、ｍａｐ＿ａｐｐが過去に取得したデータと判断する。次に、アプリケーション情報リスト１５０（図１１）を参照し、送信先アプリケーションであるグルメアプリケーション（ｇｏｕｒｍｅｔ＿ａｐｐ）が位置情報のパーミッション（ＰＥＲＭ＿ＬＯＣＡＴＩＯＮ）を保持するかを検証する。ここでは、パーミッションを保持していないため、アプリケーション間通信は不可と判断する。すなわち、パーミッションを持つ位置情報アプリケーションからパーミッションを持たないグルメアプリケーションへの位置情報の送信を防ぐことが可能である。
【００４７】
一方で、グルメアプリケーションがアプリケーション間通信で緯度・経度情報以外にカテゴリ情報を受け付ける（インタフェースを持つ）と仮定する。例えば、地図アプリケーション上で指定したレストランのカテゴリをアプリケーション間通信でグルメアプリケーションに送信することで、その周辺にあるレストランの情報が表示されるサービスがあるとする。この場合、カテゴリ情報はパーミッションとして定義されていない場合は、アプリケーション間通信は可と判定される。
【００４８】
このように、本発明は、アプリケーション間通信そのものを禁止するものではないため、利便性を損なうことはない。本発明を適用することで、送信元アプリケーションのデータ取得状況を考慮したアクセス制御が可能になる。
【００４９】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は、上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。そのような変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００５０】
１００ 情報機器
１１０ 監視部
１２０ アクセス制御部
１３０ データベース作成部
１４０ パーミッションリスト
１５０ アプリケーション情報リスト
１６０ アクセス情報データベース
１７０ 送信先リスト
【技術分野】
【０００１】
本発明は、アクセス制御システム、アクセス制御装置、及び制御方法に関する。特に、本発明は、アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御システム、アクセス制御装置、並びに、当該アクセス制御装置を制御する制御方法に関する。
【背景技術】
【０００２】
アプリケーション配信サービスは、特に、携帯電話やスマートフォン等の携帯情報端末向けのアプリケーションを配信するマーケットとして拡大している。携帯情報端末のユーザは、通信事業者や端末メーカが提供するマーケットや個人サイト等から、好みのアプリケーションを携帯情報端末へダウンロードすることによって、携帯情報端末の機能を追加したり、カスタマイズしたりすることができる。
【０００３】
ところで、アプリケーションは、携帯情報端末内の機能を利用して動作することがある。しかしながら、携帯情報端末内の機能は、不用意に利用されてしまうと、セキュリティ上の脅威となる虞がある。例えば、悪意のあるアプリケーションは、携帯情報端末内のファイルを削除してしまうこともある。
【０００４】
アプリケーションの証明書を用いるアクセス制限方法は、上述したような問題に対する対策の一つとして利用されている。アプリケーションダウンロード時にアプリケーションに付加された証明書を検証することで、アプリケーションを信頼できるもの／できないものに分け、使用可能な端末内機能を限定するという方法である。悪意のあるアプリケーションがダウンロードされても限定された機能にしかアクセスできないため、システム上の重要なトラブルは防げる。以降、機能へのアクセス権をパーミッションと呼ぶ。
【０００５】
ただし、上記方法では、アプリケーション間でデータ送受信を行ったり、サーバにデータ送信を行う場合に問題が発生する。例えば、信頼できるアプリケーション（パーミッションを持つアプリケーション）のみが取得できるデータを、信頼できないアプリケーション（パーミッションを持たないアプリケーション）に対して送信してしまうケースも考えられる。これを防ぐためには、通信を監視する仕組みが必要である。
【０００６】
特許文献１に、通信を監視するためのシステムが記載されている。特許文献１では、クライアント−サーバ間の通信を解析し、情報の漏洩を検出する機能を持つ。クライアント−サーバ間の通信を複合器又はデコンプレッサを適用し、スキャナを用いてデータを解析することで、予め登録された顧客リスト等のデジタル資産や禁止キーワードに対応する情報の漏洩を防ぐ。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−２１１７０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１に記載の高性能のネットワーク内容解析プラットフォームは、予め定められたデータの漏洩を防ぐことができる。しかしながら、特許文献１に記載の高性能のネットワーク内容解析プラットフォームは、状態によって変化するようなデータに対応することができない。例えば、携帯情報端末の位置情報は、携帯情報端末の位置によって変化する。そのため、携帯情報端末の位置情報は、アプリケーションから他のアプリケーションへ送信される場合、検出することができない。全ての位置情報を禁止情報として登録するのは現実的ではない。これを解決するためには、情報の送信元が保持する情報を考慮した監視の仕組みが必要になる。
【０００９】
また、上記解決策として、先述した証明書によるアクセス制限の仕組みにより、アプリケーション間通信を禁止することも考えられる。しかし、アプリケーション間通信を全て禁止することになり、利便性が損なわれる。このため、通信内容によって制限するような仕組みが必要になる。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明の第１の形態によると、アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御システムであって、アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報をＡＰＩから抽出する監視部と、監視部がＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するアクセス制御部とを備える。
【００１１】
また、本発明の第２の形態によると、アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御装置であって、アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報をＡＰＩから抽出する監視部と、監視部がＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するアクセス制御部とを備える。
【００１２】
また、本発明の第３の形態によると、アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御装置を制御する制御方法であって、アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報をＡＰＩから抽出する監視段階と、監視段階においてＡＰＩから抽出された情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するアクセス制御段階とを備える。
【００１３】
なおまた、上記のように発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となり得る。
【発明の効果】
【００１４】
以上の説明から明らかなように、この発明においては、アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報を前記ＡＰＩから抽出し、抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、アプリケーションからアクセス先への通信の可否を判定するようにしたので、パーミッションを持つアプリケーションからパーミッションを持たないアプリケーションへのデータ漏洩を防ぐことができる。
【００１５】
また、この発明においては、アプリケーションからアクセス先への通信そのものを許可しない訳ではなく、通信内容に応じてアクセス制御を行うため利便性を損なう虞がない。
【図面の簡単な説明】
【００１６】
【図１】一実施形態に係る情報機器１００のブロック構成の一例を示す図である。
【図２】アプリケーションＡ、監視部１１０、アクセス制御部１２０、及びデータベース作成部１３０の動作シーケンスの一例を示す図である。
【図３】パーミッションリスト１４０に記憶されているデータの一例を示す図である。
【図４】アプリケーション情報リスト１５０に記憶されているデータの一例を示す図である。
【図５】アクセス情報データベース１６０に記憶されるデータの一例を示す図である。
【図６】アプリケーションＡ、監視部１１０、及びアクセス制御部１２０の動作シーケンスの一例を示す図である。
【図７】監視部１１０が抽出するデータの一例を示す図である。
【図８】アクセス情報データベース１６０に記憶されるデータの一例を示す図である。
【図９】送信先リスト１７０に記憶されているデータの一例を示す図である。
【図１０】パーミッションリスト１４０に記憶されているデータの一例を示す図である。
【図１１】アプリケーション情報リスト１５０に記憶されているデータの一例を示す図である。
【図１２】アクセス情報データベース１６０に記憶されるデータの一例を示す図である。
【発明を実施するための形態】
【００１７】
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は、特許請求の範囲にかかる発明を限定するものではなく、また、実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１８】
図１は、一実施形態に係る情報機器１００のブロック構成の一例を示す。情報機器１００は、アプリケーションから他のアプリケーションへのデータのアクセスを制御する。なおまた、情報機器１００は、この発明における「アクセス制御装置」の一例であってよい。また、他のアプリケーションは、この発明における「アクセス先」の一例であってよい。
【００１９】
携帯機器１００は、監視部１１０、アクセス制御部１２０、データベース作成部１３０、パーミッションリスト１４０、アプリケーション情報リスト１５０、及びアクセス情報データベース１６０を備える。以下に、各構成要素の機能及び動作を説明する。
【００２０】
監視部１１０は、アプリケーションによるパーミッション対象ＡＰＩの発行を監視する。そして、監視部１１０は、パーミッション対象ＡＰＩの発行を検知すると、発行元アプリケーションＩＤと、ＡＰＩ情報とをアクセス制御部１２０に渡す。また、監視部１１０は、アプリケーション間の通信や外部との通信ＡＰＩも監視する。そして、監視部１１０は、ＡＰＩの発行を検知すると、発行元アプリケーションＩＤと、送信先アプリケーションＩＤと、送信するデータとをアクセス制御部１２０に渡す。
【００２１】
アクセス制御部１２０は、パーミッションリスト１４０とアプリケーション情報リスト１５０とを参照して、ＡＰＩの実行可否を判定する。ＡＰＩ発行元のアプリケーションがパーミッションを保持していない場合はＡＰＩの実行を不可と判定する。これに加え、アクセス制御部１２０は、アプリケーション情報リスト１５０とアクセス情報データベース１６０を参照して、アプリケーション間の通信や外部との通信ＡＰＩの実行可否の判定も行う。送信先のアプリケーションが送信データに対応するパーミッションを保持していない場合は通信不可と判定する。
【００２２】
データベース作成部１３０は、パーミッション対象ＡＰＩを解析し、発行元アプリケーションとパーミッション対象ＡＰＩによって取得したデータを管理するため、アクセス情報データベース１６０の操作を行う。
【００２３】
パーミッションリスト１４０は、パーミッションと、そのパーミッションに紐付けられるＡＰＩとを記憶している。
【００２４】
アプリケーション情報リスト１５０は、アプリケーションと、そのアプリケーションが利用可能なパーミッションとを記憶している。
【００２５】
アクセス情報データベース１６０は、アプリケーションによって発行されたパーミッション対象ＡＰＩと取得したデータの履歴を蓄積する。
【００２６】
図２は、アプリケーションＡ、監視部１１０、アクセス制御部１２０、及びデータベース作成部１３０の動作シーケンスの一例を示す。図３は、パーミッションリスト１４０に記憶されているデータの一例を示す。図４は、アプリケーション情報リスト１５０に記憶されているデータの一例を示す。図５は、アクセス情報データベース１６０に記憶されるデータの一例を示す。以下、アクセス情報データベース作成処理について説明する。
【００２７】
アプリケーション（アプリケーションＡ）がパーミッション対象であるＡＰＩ１の呼出しを行ったとする（Ｓ１０１）。
【００２８】
監視部１１０は、ＡＰＩ１が呼ばれたことを検知し、アクセス制御部１２０にアクセス制御処理を依頼する（Ｓ１０２）。この際、ＡＰＩ発行元のアプリケーションＩＤ（アプリケーションＡ）とＡＰＩ名（ＡＰＩ１）を通知する。
【００２９】
アクセス制御部１２０は、監視部１１０から渡された情報をもとにアクセス可否判定を行う（Ｓ１０３）。より具体的には、まず、ＡＰＩ名をもとにパーミッションリスト１４０を参照することで、発行されたＡＰＩに対応するパーミッションを取得する。パーミッションリスト１４０の例を図３に示す。ここでは、発行されたＡＰＩ１に対応するパーミッションは、パーミッション１であることがわかる。次に、アクセス制御部１２０は、パーミッション情報をもとにアプリケーション情報リスト１５０を参照することで、発行元アプリケーションがそのパーミッションを保持するか否かを判定する。アプリケーション情報リスト１５０の例を図４に示す。ここでは、アプリケーションＡは、パーミッション１を利用可能であることがわかる。このため、アクセス可と判定される。そして、アクセス制御部１２０は、その判定結果を監視部１１０へ通知する（Ｓ１０４）。
【００３０】
アクセス不可の場合、監視部１１０は、アプリケーションに対し、その旨を通知する（Ｓ１０５）。アクセス可の場合はＡＰＩ１が実行され、監視部１１０は、ＡＰＩ１によって得られたデータ（データ１）を取得する（Ｓ１０６）。次に、監視部１１０は、データベース作成部１３０にデータベース作成依頼を行う（Ｓ１０７）。この際、発行元のアプリケーションＩＤ（アプリケーションＡ）と、ＡＰＩ１によって取得したデータ（データ１）を通知する。
【００３１】
データベース作成部１３０は、監視部１１０から渡された情報をもとにアクセス情報データベースを作成する（Ｓ１０８）。アクセス情報データベース１６０の例を図５に示す。図５のように、アプリケーションＡが使用したパーミッションと取得したデータの履歴が保存される。以上が、アクセス情報データベース作成処理である。
【００３２】
図６は、アプリケーションＡ、監視部１１０、及びアクセス制御部１２０の動作シーケンスの一例を示す。図７は、監視部１１０が抽出するデータの一例を示す。図８は、アクセス情報データベース１６０に記憶されるデータの一例を示す。以下、アクセス制御処理について説明する。
【００３３】
まず、アプリケーション（アプリケーションＡ）は他のアプリケーション（アプリケーションＢ）とアプリケーション間通信を行うためＡＰＩの呼出しを行う（Ｓ２０１）。
【００３４】
監視部１１０は、ＡＰＩの呼出しを検知し、ＡＰＩの解析を行う（Ｓ２０２）。ここでは、図７のように、送信元アプリケーションＩＤと通信先アプリケーションＩＤ、送信するデータを抽出する。次に、抽出したデータを付加し、アクセス制御部１２０にアクセス制御処理を依頼する（Ｓ２０３）。
【００３５】
アクセス制御部１２０は、監視部１１０から渡された情報をもとにアクセス可否判定を行う（Ｓ２０４）。より具体的には、まず、アクセス情報データベース１６０を参照することで、送信元アプリケーションが送信するデータを過去に取得しているか否かを判定し、取得している場合はそのパーミッションを取得する。ここでは、図５に示したようにアプリケーションＡは、データ１を取得しているため、そのパーミッションであるパーミッション１を取得する。次に、アクセス制御部１２０は、アプリケーション情報リスト１５０を参照することで、送信先アプリケーションであるアプリケーションＢがパーミッション１を使用可能か否かを判定する。ここでは、図４に示すように、アプリケーションＢはパーミッション１を保持しないため、使用できないと判定される。よって、アプリケーションＡによるアプリケーション間通信ＡＰＩは不可と判定される。そして、アクセス制御部１２０は、判定結果を監視部１１０へ通知する（Ｓ２０５）。
【００３６】
アクセス不可の場合、監視部１１０は、アプリケーションに対し、その旨を通知する（Ｓ２０６）。
【００３７】
以上が、アクセス制御処理である。なおまた、Ｓ２０４でアクセス可と判定された場合は、アプリケーション間通信ＡＰＩが実行される。その後、図２で説明したアクセス情報データベース作成処理へと遷移する。すなわち、アプリケーションＢは、パーミッション１を使用し、データ１を取得したものとされる。これを図８に示す。
【００３８】
以上説明したように、本実施の形態によると、パーミッション対象のＡＰＩを監視することで、そのＡＰＩによって得られたデータを蓄積することができる。これにより、通信時に通信内容を解析することで、以前取得したデータが含まれているかがわかる。このため、そのデータに対応するパーミッションを送信先が保持しているかによって通信の可否を判定することができる。結果、パーミッションを持たないアプリケーションへの情報漏えいを防ぐことができる。
【００３９】
図９は、送信先リスト１７０に記憶されているデータの一例を示す。以上の説明においては、監視する通信をアプリケーション間通信としていたが、これに限らない。すなわち、インターネット上のサーバに通信する際にも適用できる。例えば、図９に示す送信先リスト１７０を追加し、アクセス制御部１２０が参照することで実現できる。送信先リスト１７０には、送信先サーバＩＤとそのサーバに送信可能なパーミッション情報が記載されている。サーバＩＤは、例えばＵＲＬである。
【００４０】
この際の処理の流れは、上記の実施の形態におけるアクセス制御処理と同様であるが、アクセス制御部１２０は、サーバへの通信である場合は、アプリケーション情報リスト１５０ではなく、上記送信先リスト１７０を参照することで、送信先サーバがパーミッションを保持しているか否かを判定し、通信可否を判定する。
【００４１】
また、図１のパーミッションリスト１４０は、予め用意されているものとしていたがこれに限らない。すなわち、ダウンローダによってアプリケーションが検証され、アプリケーションとそのアプリケーションが使用可能なパーミッションのリストが追加されてもよい。この場合、情報機器１００に予め登録されているアプリケーションだけでなく、アプリケーション配信サービスからダウンロードするアプリケーションに対しても本発明を適用することができる。すなわち、情報機器１００上で動作する全てのアプリケーションが対象である。
【００４２】
また、パーミッションリスト１４０とアプリケーション情報リスト１５０を別々にしていたが、これに限らない。アプリケーションＩＤ、パーミッション、ＡＰＩ名を保持する１つのリストとして管理してもよい。アクセス制御部１２０は、図２のＳ２０３においてアクセス可否を判定する際、アプリケーションＩＤとＡＰＩ名から、ＡＰＩ発行元アプリケーションがパーミッションを保持するか否かを判断することができる。
【００４３】
また、図６のＳ６０４にて、送信するデータを過去に取得しているか否かを判定する際、完全一致を前提としていたが、これに限らない。すなわち、例えば、送信するデータが、「取得したデータは、データ１である」という内容であった場合、送信元アプリケーションが以前取得した「データ１」が含まれていると判断する。
【００４４】
図１０は、パーミッションリスト１４０に記憶されているデータの一例を示す。図１１は、アプリケーション情報リスト１５０に記憶されているデータの一例を示す。図１２は、アクセス情報データベース１６０に記憶されるデータの一例を示す。次に、具体的な実施例を用いて本発明を実施するための最良の形態の動作を説明する。本実施例では、携帯端末において、位置情報を取得するパーミッションを保持する地図アプリケーションが、パーミッションを持たないグルメアプリケーションにアプリケーション間通信で送信する例を説明する。
【００４５】
まず、アクセス情報データベース作成処理を説明する。地図アプリケーションは、実行中に位置情報を取得するためにＡＰＩ（ｇｅｔＬｏｃａｔｉｏｎ（））を呼ぶ。ｇｅｔＬｏｃａｔｉｏｎ（）内には監視部１１０が（別のＡＰＩ等で）組み込まれており、地図アプリケーションがｇｅｔＬｏｃａｔｉｏｎ（）を呼んだことを検知できる。この際、監視部１１０は、地図アプリケーションのＩＤ（ｍａｐ＿ａｐｐ）とＡＰＩ名（ｇｅｔＬｏｃａｔｉｏｎ）をアクセス制御部１２０に通知する。アクセス制御部１２０は、図１０のパーミッションリスト１４０と図１１のアプリケーション情報リスト１５０を参照することで、図２のＳ２０３で説明したアクセス可否判定を行う。地図アプリケーションは位置情報を取得するパーミッションを保持するため、アクセス可と判定される。アクセス可と判定されると、制御が監視部１１０に遷移し、監視部１１０はｇｅｔＬｏｃａｔｉｏｎ（）によって取得した位置情報（緯度・経度情報）を取得する。次に、取得した位置情報、パーミッション、呼出し元アプリケーションＩＤをもとにアクセス情報データベース１６０を作成する。すでに情報が格納されている場合は、追加していくことで履歴を作成する。作成後のアクセス情報データベース１６０を図１２に示す。
【００４６】
次に、アクセス制御処理を説明する。地図アプリケーションは、アプリケーション間通信ＡＰＩ（ｓｅｎｄＤａｔａ（））を呼ぶ。ｓｅｎｄＤａｔａ（）のフォーマットは第一引数に送信先アプリケーションＩＤ、第二引数にデータを指定することとする（ｓｅｎｄＤａｔａ（”ｇｏｕｒｍｅｔ＿ａｐｐ”， ”３５．４５， １３５．４５”））。ｓｅｎｄＤａｔａ（）内には監視部１１０が組み込まれており、地図アプリケーションがｓｅｎｄＤａｔａ（）を呼んだことを検知できる。この際、監視部１１０は、送信元アプリケーションＩＤ（ｍａｐ＿ａｐｐ）、送信先アプリケーションＩＤ（ｇｏｕｒｍｅｔ＿ａｐｐ）、送信データ（３５．４５， １３５．４５）をアクセス制御部１２０に通知する。アクセス制御部１２０は、送信データをキーにして、アクセス情報データベース１６０（図１２）を参照することで、送信するデータがＰＥＲＭ＿ＬＯＣＡＴＩＯＮに関連する情報であり、ｍａｐ＿ａｐｐが過去に取得したデータと判断する。次に、アプリケーション情報リスト１５０（図１１）を参照し、送信先アプリケーションであるグルメアプリケーション（ｇｏｕｒｍｅｔ＿ａｐｐ）が位置情報のパーミッション（ＰＥＲＭ＿ＬＯＣＡＴＩＯＮ）を保持するかを検証する。ここでは、パーミッションを保持していないため、アプリケーション間通信は不可と判断する。すなわち、パーミッションを持つ位置情報アプリケーションからパーミッションを持たないグルメアプリケーションへの位置情報の送信を防ぐことが可能である。
【００４７】
一方で、グルメアプリケーションがアプリケーション間通信で緯度・経度情報以外にカテゴリ情報を受け付ける（インタフェースを持つ）と仮定する。例えば、地図アプリケーション上で指定したレストランのカテゴリをアプリケーション間通信でグルメアプリケーションに送信することで、その周辺にあるレストランの情報が表示されるサービスがあるとする。この場合、カテゴリ情報はパーミッションとして定義されていない場合は、アプリケーション間通信は可と判定される。
【００４８】
このように、本発明は、アプリケーション間通信そのものを禁止するものではないため、利便性を損なうことはない。本発明を適用することで、送信元アプリケーションのデータ取得状況を考慮したアクセス制御が可能になる。
【００４９】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は、上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。そのような変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００５０】
１００ 情報機器
１１０ 監視部
１２０ アクセス制御部
１３０ データベース作成部
１４０ パーミッションリスト
１５０ アプリケーション情報リスト
１６０ アクセス情報データベース
１７０ 送信先リスト
【特許請求の範囲】
【請求項１】
アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御システムであって、
アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、前記ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報を前記ＡＰＩから抽出する監視部と、
前記監視部が前記ＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、前記アプリケーションからアクセス先への通信の可否を判定するアクセス制御部と
を備えるアクセス制御システム。
【請求項２】
ＡＰＩ呼出し元アプリケーション情報とアクセス権名とＡＰＩによって取得したデータとを紐付けて管理するデータベースを作成するデータベース作成部
を更に備え、
前記アクセス制御部は、前記データベース作成部によって作成されたデータベース内に蓄積されたデータに基づいて、通信に含まれるデータに対応するアクセス権を通信先が保持しているか否かを判別する
請求項１に記載のアクセス制御システム。
【請求項３】
前記監視部は、アプリケーションから他のアプリケーションへのＡＰＩの呼出しを検知するように監視する
請求項１又は２に記載のアクセス制御システム。
【請求項４】
前記監視部は、アプリケーションから外部の通信網を介してアクセスするアクセス先へのＡＰＩの呼出しを検知するように監視する
請求項１から３のいずれか一項に記載のアクセス制御システム。
【請求項５】
前記監視部は、前記ＡＰＩの呼出しを検知した場合、アクセスの可否判定を行うために必要な情報として、当該ＡＰＩの呼出しを行ったアプリケーションの識別情報を前記ＡＰＩから抽出する
請求項１から４のいずれか一項に記載のアクセス制御システム。
【請求項６】
前記監視部は、前記ＡＰＩの呼出しを検知した場合、アクセスの可否判定を行うために必要な情報として、アクセス先の識別情報を前記ＡＰＩから抽出する
請求項１から５のいずれか一項に記載のアクセス制御システム。
【請求項７】
前記監視部は、前記ＡＰＩの呼出しを検知した場合、アクセスの可否判定を行うために必要な情報として、当該ＡＰＩの呼出しに関連してアプリケーションからアクセス先へ送信されるデータを前記ＡＰＩから抽出する
請求項１から６のいずれか一項に記載のアクセス制御システム。
【請求項８】
前記ＡＰＩ毎に紐付けられたアクセス権の設定を記憶するパーミッションリスト
を更に備え、
前記アクセス制御部は、前記パーミッションリストに記憶されている前記ＡＰＩ毎に紐付けられたアクセス権の設定に基づいて、前記アプリケーションからアクセス先への通信の可否を判定する
請求項１から７のいずれか一項に記載のアクセス制御システム。
【請求項９】
アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御装置であって、
アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、前記ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報を前記ＡＰＩから抽出する監視部と、
前記監視部が前記ＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、前記アプリケーションからアクセス先への通信の可否を判定するアクセス制御部と
を備えるアクセス制御装置。
【請求項１０】
アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御装置を制御する制御方法であって、
アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、前記ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報を前記ＡＰＩから抽出する監視段階と、
前記監視段階において前記ＡＰＩから抽出された情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、前記アプリケーションからアクセス先への通信の可否を判定するアクセス制御段階と
を備える制御方法。
【請求項１】
アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御システムであって、
アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、前記ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報を前記ＡＰＩから抽出する監視部と、
前記監視部が前記ＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、前記アプリケーションからアクセス先への通信の可否を判定するアクセス制御部と
を備えるアクセス制御システム。
【請求項２】
ＡＰＩ呼出し元アプリケーション情報とアクセス権名とＡＰＩによって取得したデータとを紐付けて管理するデータベースを作成するデータベース作成部
を更に備え、
前記アクセス制御部は、前記データベース作成部によって作成されたデータベース内に蓄積されたデータに基づいて、通信に含まれるデータに対応するアクセス権を通信先が保持しているか否かを判別する
請求項１に記載のアクセス制御システム。
【請求項３】
前記監視部は、アプリケーションから他のアプリケーションへのＡＰＩの呼出しを検知するように監視する
請求項１又は２に記載のアクセス制御システム。
【請求項４】
前記監視部は、アプリケーションから外部の通信網を介してアクセスするアクセス先へのＡＰＩの呼出しを検知するように監視する
請求項１から３のいずれか一項に記載のアクセス制御システム。
【請求項５】
前記監視部は、前記ＡＰＩの呼出しを検知した場合、アクセスの可否判定を行うために必要な情報として、当該ＡＰＩの呼出しを行ったアプリケーションの識別情報を前記ＡＰＩから抽出する
請求項１から４のいずれか一項に記載のアクセス制御システム。
【請求項６】
前記監視部は、前記ＡＰＩの呼出しを検知した場合、アクセスの可否判定を行うために必要な情報として、アクセス先の識別情報を前記ＡＰＩから抽出する
請求項１から５のいずれか一項に記載のアクセス制御システム。
【請求項７】
前記監視部は、前記ＡＰＩの呼出しを検知した場合、アクセスの可否判定を行うために必要な情報として、当該ＡＰＩの呼出しに関連してアプリケーションからアクセス先へ送信されるデータを前記ＡＰＩから抽出する
請求項１から６のいずれか一項に記載のアクセス制御システム。
【請求項８】
前記ＡＰＩ毎に紐付けられたアクセス権の設定を記憶するパーミッションリスト
を更に備え、
前記アクセス制御部は、前記パーミッションリストに記憶されている前記ＡＰＩ毎に紐付けられたアクセス権の設定に基づいて、前記アプリケーションからアクセス先への通信の可否を判定する
請求項１から７のいずれか一項に記載のアクセス制御システム。
【請求項９】
アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御装置であって、
アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、前記ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報を前記ＡＰＩから抽出する監視部と、
前記監視部が前記ＡＰＩから抽出した情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、前記アプリケーションからアクセス先への通信の可否を判定するアクセス制御部と
を備えるアクセス制御装置。
【請求項１０】
アプリケーションからアクセス先へのデータのアクセスを制御するアクセス制御装置を制御する制御方法であって、
アプリケーションからアクセス先へのＡＰＩの呼出しを検知するように監視し、前記ＡＰＩの呼出しを検知した場合に、アクセスの可否判定を行うために必要な情報を前記ＡＰＩから抽出する監視段階と、
前記監視段階において前記ＡＰＩから抽出された情報に基づいて、アプリケーションからアクセス先へ送信されるデータに対応するアクセス権をアクセス先が保持しているか否かに応じて、前記アプリケーションからアクセス先への通信の可否を判定するアクセス制御段階と
を備える制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１２−１１８８４２（Ｐ２０１２−１１８８４２Ａ）
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１０−２６９１１２（Ｐ２０１０−２６９１１２）
【出願日】平成２２年１２月２日（２０１０．１２．２）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２２年１２月２日（２０１０．１２．２）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]