(57)【要約】【課題】グループ（テナント）を統合する場合に、統合後の設定変更に要する負担を軽減しつつ、統合後のグループにおけるセキュリティを確保する。【解決手段】管理サーバ１４は、テナントＡ１０に属するユーザ、及びテナントＢ１２に属するユーザ毎に、その所属するドメインの認証レベルを記憶部１４ｅに記憶する。また、認証レベルと統合後のセキュリティレベルとの関係を規定する統合ポリシーテーブル１４ｅ３を記憶部１４ｅに記憶する。管理サーバ１４は、テナントＡ１０とテナントＢ１２を統合する場合に、認証レベルと統合ポリシーテーブル１４ｅ３を用いて統合後のテナントに属するユーザ毎にセキュリティレベルを適応的に設定する。【選択図】図１
2020038548.tif 000002
【特許請求の範囲】
【請求項１】
第１グループに属するユーザ、及び第２グループに属するユーザ毎に、その所属するドメインの認証レベルを記憶する記憶手段と、
前記認証レベルと統合後のセキュリティレベルとの関係を規定する統合ポリシーを設定する統合ポリシー設定手段と、
前記第１グループと前記第２グループを統合して第３グループを構成する場合に、前記認証レベルと前記統合ポリシーとを用いて前記第３グループに属するユーザ毎にセキュリティレベルを設定するセキュリティレベル設定手段と、
を備える管理装置。
【請求項２】
第３グループのユーザ毎に、前記統合ポリシーを用いてサービス利用ライセンスを設定するライセンス設定手段
をさらに備える請求項１に記載の管理装置。
【請求項３】
第３グループのユーザ毎に、前記統合ポリシーを用いてサービスの管理者権限を設定する権限設定手段
をさらに備える請求項１，２のいずれかに記載の管理装置。
【請求項４】
前記記憶手段は、ユーザ毎の使用頻度を記憶し、
前記セキュリティレベル設定手段は、前記認証レベルと前記統合ポリシーと前記使用頻度を用いて前記第３グループに属するユーザ毎にセキュリティレベルを設定する
請求項１に記載の管理装置。
【請求項５】
前記認証レベルには、第１認証レベルと、前記第１認証レベルよりも相対的に低い第２認証レベルと、未認証レベルを含み、
前記セキュリティレベル設定手段は、前記第１認証レベルのユーザを認証済みユーザ、前記第２認証レベルのユーザ及び前記未認証レベルのユーザをゲストユーザに設定する
請求項１に記載の管理装置。
【請求項６】
前記認証レベルには、第１認証レベルと、前記第１認証レベルよりも相対的に低い第２認証レベルと、未認証レベルを含み、
前記セキュリティレベル設定手段は、前記第１認証レベル及び前記第２認証レベルのユーザを認証済みユーザ、前記未認証レベルのユーザをゲストユーザに設定する
請求項１に記載の管理装置。
【請求項７】
前記認証レベルには、第１認証レベルと、前記第１認証レベルよりも相対的に低い第２認証レベルと、未認証レベルを含み、
前記セキュリティレベル設定手段は、前記第２グループが前記第１グループに吸収されることで統合される場合、前記第２グループのユーザについては認証レベルによらずにゲストユーザに設定する
請求項１に記載の管理装置。
【請求項８】
前記認証レベルには、第１認証レベルと、前記第１認証レベルよりも相対的に低い第２認証レベルと、未認証レベルを含み、
前記ライセンス設定手段は、前記第１認証レベルのユーザにサービス利用ライセンスを付与し、前記第２認証レベルのユーザ及び未認証レベルのユーザにはサービス利用ライセンスを付与しない
請求項２に記載の管理装置。
【請求項９】
前記認証レベルには、第１認証レベルと、前記第１認証よりも相対的に低い第２認証レベルと、未認証レベルを含み、
前記ライセンス設定手段は、前記第２グループが前記第１グループに吸収されることで統合される場合、前記第２グループのユーザについては認証レベルによらずにサービス利用ライセンスを付与しない
請求項２に記載の管理装置。
【請求項１０】
前記権限設定手段は、統合前に管理者権限を有していたユーザについては認証レベルによらずにそのまま管理者権限を付与する
請求項３に記載の管理装置。
【請求項１１】
前記権限設定手段は、前記第２グループが前記第１グループに吸収されることで統合される場合、前記第２グループのユーザについては認証レベルによらずに管理者権限を付与しない
請求項３に記載の管理装置。
【請求項１２】
コンピュータを、
第１グループに属するユーザ、及び第２グループに属するユーザ毎に、その所属するドメインの認証レベルを記憶する記憶手段と、
前記認証レベルと統合後のセキュリティレベルとの関係を規定する統合ポリシーを設定する統合ポリシー設定手段と、
前記第１グループと前記第２グループを統合して第３グループを構成する場合に、前記認証レベルと前記統合ポリシーとを用いて前記第３グループに属するユーザ毎にセキュリティレベルを設定するセキュリティレベル設定手段
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理装置及びプログラムに関する。
【背景技術】
【０００２】
クラウドサービスにおいて、複数のテナント（クラウドサービスを利用するユーザを管理する単位：グループ）毎にサービスを提供するマルチテナント型サービスが知られている。
【０００３】
特許文献１には、マルチテナント型サービスを提供するシステムにおいて、テナントの統合や分割を行う場合のシステム移行の労力を軽減する技術が記載されている。サーバは、ユーザを識別するユーザ識別情報に関連付けて、当該ユーザの属するグループを管理するユーザ情報管理手段と、１又は複数の機器ごとに、当該機器が属する主グループと、当該機器の利用を許可する前記主グループとは異なる副グループの２つのグループの情報を関連付けて管理する機器情報管理手段と、情報端末から機器の利用要求を受け付けた場合に、情報端末を操作するユーザのグループが、利用要求に係る機器の主グループと一致するか否かを判定する第１判定手段と、第１判定手段により一致しないと判定された場合に、情報端末を操作するユーザのグループが、利用要求に係る機器の副グループが格納するグループのいずれかと一致するか否かを判定する第２判定手段と、当該情報端末を操作するユーザのユーザ識別情報に関連付けてユーザ情報管理手段により管理されるグループが、第１判定手段又は第２判定手段のいずれかにより、利用要求に係る機器に関連付けて機器情報管理手段に管理される主グループ又は副グループの中に含まれるか否かに応じて、利用要求に係る機器の利用を制御する制御手段を含む管理装置が記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第５９１０２１８号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
グループ（テナント）を統合する場合に、統合前のグループに登録されているユーザを統合後のグループに自動登録するときに、ユーザのセキュリティレベルについて考慮しないと、セキュリティレベルの低いユーザを統合対象とするとセキュリティ上の問題が生じ得る。統合後にユーザ毎にセキュリティレベルを変更することも考えられるが、ユーザ数が増大するほどその設定変更に要する負担が増大する。
【０００６】
本発明は、グループ（テナント）を統合する場合に、統合後の設定変更に要する負担を軽減しつつ、統合後のグループにおけるセキュリティを確保することを目的とする。
【課題を解決するための手段】
【０００７】
請求項１に記載の発明は、第１グループに属するユーザ、及び第２グループに属するユーザ毎に、その所属するドメインの認証レベルを記憶する記憶手段と、前記認証レベルと統合後のセキュリティレベルとの関係を規定する統合ポリシーを設定する統合ポリシー設定手段と、前記第１グループと前記第２グループを統合して第３グループを構成する場合に、前記認証レベルと前記統合ポリシーとを用いて前記第３グループに属するユーザ毎にセキュリティレベルを設定するセキュリティレベル設定手段とを備える管理装置である。
【０００８】
請求項２に記載の発明は、第３グループのユーザ毎に、前記統合ポリシーを用いてサービス利用ライセンスを設定するライセンス設定手段をさらに備える請求項１に記載の管理装置である。
【０００９】
請求項３に記載の発明は、第３グループのユーザ毎に、前記統合ポリシーを用いてサービスの管理者権限を設定する権限設定手段をさらに備える請求項１，２のいずれかに記載の管理装置である。
【００１０】
請求項４に記載の発明は、前記記憶手段は、ユーザ毎の使用頻度を記憶し、前記セキュリティレベル設定手段は、前記認証レベルと前記統合ポリシーと前記使用頻度を用いて前記第３グループに属するユーザ毎にセキュリティレベルを設定する請求項１に記載の管理装置である。
【００１１】
請求項５に記載の発明は、前記認証レベルには、第１認証レベルと、前記第１認証レベルよりも相対的に低い第２認証レベルと、未認証レベルを含み、前記セキュリティレベル設定手段は、前記第１認証レベルのユーザを認証済みユーザ、前記第２認証レベルのユーザ及び前記未認証レベルのユーザをゲストユーザに設定する請求項１に記載の管理装置である。
【００１２】
請求項６に記載の発明は、前記認証レベルには、第１認証レベルと、前記第１認証レベルよりも相対的に低い第２認証レベルと、未認証レベルを含み、前記セキュリティレベル設定手段は、前記第１認証レベル及び前記第２認証レベルのユーザを認証済みユーザ、前記未認証レベルのユーザをゲストユーザに設定する請求項１に記載の管理装置である。
【００１３】
請求項７に記載の発明は、前記認証レベルには、第１認証レベルと、前記第１認証レベルよりも相対的に低い第２認証レベルと、未認証レベルを含み、前記セキュリティレベル設定手段は、前記第２グループが前記第１グループに吸収されることで統合される場合、前記第２グループのユーザについては認証レベルによらずにゲストユーザに設定する請求項１に記載の管理装置である。
【００１４】
請求項８に記載の発明は、前記認証レベルには、第１認証レベルと、前記第１認証レベルよりも相対的に低い第２認証レベルと、未認証レベルを含み、前記ライセンス設定手段は、前記第１認証レベルのユーザにサービス利用ライセンスを付与し、前記第２認証レベルのユーザ及び未認証レベルのユーザにはサービス利用ライセンスを付与しない請求項２に記載の管理装置である。
【００１５】
請求項９に記載の発明は、前記認証レベルには、第１認証レベルと、前記第１認証よりも相対的に低い第２認証レベルと、未認証レベルを含み、前記ライセンス設定手段は、前記第２グループが前記第１グループに吸収されることで統合される場合、前記第２グループのユーザについては認証レベルによらずにサービス利用ライセンスを付与しない請求項２に記載の管理装置である。
【００１６】
請求項１０に記載の発明は、前記権限設定手段は、統合前に管理者権限を有していたユーザについては認証レベルによらずにそのまま管理者権限を付与する請求項３に記載の管理装置である。
【００１７】
請求項１１に記載の発明は、前記権限設定手段は、前記第２グループが前記第１グループに吸収されることで統合される場合、前記第２グループのユーザについては認証レベルによらずに管理者権限を付与しない請求項３に記載の管理装置である。
【００１８】
請求項１２に記載の発明は、コンピュータを、第１グループに属するユーザ、及び第２グループに属するユーザ毎に、その所属するドメインの認証レベルを記憶する記憶手段と、前記認証レベルと統合後のセキュリティレベルとの関係を規定する統合ポリシーを設定する統合ポリシー設定手段と、前記第１グループと前記第２グループを統合して第３グループを構成する場合に、前記認証レベルと前記統合ポリシーとを用いて前記第３グループに属するユーザ毎にセキュリティレベルを設定するセキュリティレベル設定手段として機能させるためのプログラムである。
【発明の効果】
【００１９】
請求項１，１２に記載の発明によれば、グループ（テナント）を統合する場合に、統合後の設定変更に要する負担を軽減しつつ、統合後のグループにおけるセキュリティを確保できる。
【００２０】
請求項２に記載の発明によれば、さらに、統合後のグループにおけるサービス利用ライセンスを設定できる。
【００２１】
請求項３に記載の発明によれば、さらに、統合後のグループにおけるサービスの管理者権限を設定できる。
【００２２】
請求項４に記載の発明によれば、さらに、ユーザの使用頻度を用いてセキュリティレベルを設定できる。
【００２３】
請求項５〜１１に記載の発明によれば、さらに、認証レベルに応じてセキュリティレベル等を適応的に設定できる。
【図面の簡単な説明】
【００２４】
【図１】実施形態のシステム構成図である。
【図２Ａ】実施形態の統合前のテナント説明図である。
【図２Ｂ】実施形態の統合後のテナント説明図である。
【図３】実施形態のテナントユーザ管理テーブル説明図である。
【図４】実施形態のドメイン管理テーブル説明図である。
【図５】実施形態のオンラインによるドメイン実在性確認模式図である。
【図６】実施形態のドメイン認証レベルの説明図である。
【図７】実施形態の統合ポリシーテーブル説明図である。
【図８Ａ】実施形態の処理フローチャート（その１）である。
【図８Ｂ】実施形態の処理フローチャート（その２）である。
【図９】実施形態の更新されたテナントユーザ管理テーブル説明図である。
【図１０】実施形態の更新されたドメイン管理テーブル説明図である。
【図１１】実施形態の統合処理模式図である。
【図１２】実施形態の他の統合ポリシーテーブル説明図である。
【図１３】実施形態のさらに他の統合ポリシーテーブル説明図である。
【図１４】実施形態の他のテナントユーザ管理テーブル説明図である。
【図１５】実施形態のサービス管理テーブル説明図である。
【図１６】実施形態のさらに他の統合ポリシーテーブル説明図である。
【図１７】実施形態の他の統合処理模式図である。
【図１８】実施形態の他の更新されたテナントユーザ管理テーブル説明図である。
【図１９】実施形態の更新されたサービス管理テーブル説明図である。
【図２０】実施形態のさらに他のテナントユーザ管理テーブル説明図である。
【図２１】実施形態のさらに他のサービス管理テーブル説明図である。
【図２２】実施形態のさらに他の統合ポリシーテーブル説明図である。
【図２３】実施形態のさらに他の更新されたテナントユーザ管理テーブル説明図である。
【図２４】実施形態のさらに他の更新されたサービス管理テーブル説明図である。
【図２５】変形例の統合ポリシーテーブル説明図である。
【発明を実施するための形態】
【００２５】
以下、図面に基づき本発明の実施形態について説明する。
【００２６】
図１は、本実施形態におけるシステム構成を示す。システムは、クラウドサービスを利用するユーザの単位であるテナントを複数含み、図１ではテナントＡ１０及びテナントＢ１２を含む。テナントＡ１０及びテナントＢ１２は、インターネット等のネットワーク１６に接続される。他方、管理サーバ１４がネットワーク１６に接続される。管理サーバ１４は、テナントＡ１０及びテナントＢ１２の動作を制御する。具体的には、テナントＡ１０及びテナントＢ１２は、それぞれ情報端末及びデバイスを備えており、情報端末からの要求を管理サーバ１４で処理して各テナントのデバイスの動作を制御する。
【００２７】
管理サーバ１４は、テナントＡ１０及びテナントＢ１２に含まれるデバイスの情報を管理するとともに、テナントＡ１０及びテナントＢ１２に含まれるデバイスの利用が情報端末から要求されると、その要求に基づいてデバイスの利用を制御するサーバコンピュータである。管理サーバ１４は、機能ブロックとして、通信インターフェイス（Ｉ／Ｆ）１４ａ、入力部１４ｂ、表示部１４ｃ、制御部１４ｄ、及び記憶部１４ｅを備える。
【００２８】
通信Ｉ／Ｆ１４ａは、ネットワーク１６を介してテナントＡ１０、Ｂ１２からの要求を受け付け、当該要求を処理してネットワーク１６を介してテナントＡ１０、Ｂ１２に出力する。
【００２９】
入力部１４ｂは、統合ポリシー設定手段として機能し、管理者の操作により、テナントＡ１０及びテナントＢ１２の統合が行われる場合の処理のルールである統合ポリシーを入力する。
【００３０】
表示部１４ｃは、入力された統合ポリシー等を表示する。
【００３１】
記憶部１４ｅは、テナントユーザ管理テーブル１４ｅ１、ドメイン管理テーブル１４ｅ２、及び統合ポリシーテーブル１４ｅ３を記憶する。
【００３２】
制御部１４ｄは、セキュリティレベル設定手段として機能し、テナントＡ１０及びテナントＢ１２の統合が行われる場合の、テナントＡ１０のユーザ、及びテナントＢ１２のユーザのセキュリティレベルを制御する。具体的には、制御部１４ｄは、記憶部１４ｅに記憶されたテナントユーザ管理テーブル１４ｅ１、ドメイン管理テーブル１４ｅ２、及び統合ポリシーテーブル１４ｅ３を参照することで、統合対象テナントに属するユーザのセキュリティレベルを設定する。テナントＡ１０及びテナントＢ１２を統合する、例えば、テナントＡ１０がテナントＢ１２を吸収合併することで統合する場合に、統合前のテナントＢ１２に登録されているユーザを統合後のテナントＡ１０に自動登録するときに、統合前のテナントＢ１２に属していたユーザのセキュリティレベルについて考慮しないと、セキュリティレベルの低いユーザを統合対象とするとセキュリティ上の問題が生じ得る。仮に、統合後にユーザ毎にセキュリティレベルを変更する場合には、ユーザ数が増大するほどその設定変更に要する負担が増大してしまう。
【００３３】
そこで、本実施形態では、統合ポリシーによってテナントＢ１２に属するユーザのセキュリティレベルについての取り扱いを一律に規定し、制御部１４ｄは、この統合ポリシーを参照して統合対象であるテナントＢ１２に属するユーザの統合後のテナントにおけるセキュリティレベルを適応的に設定する。
【００３４】
管理サーバ１４は、サーバコンピュータとしての構成、すなわち、１又は複数のプロセッサ、ＲＯＭ、ＲＡＭ、各種インターフェイス、キーボードやマウス等の入力装置、ディスプレイ等の出力装置、及びＨＤＤ（ハードディスクドライブ）やＳＤＤ（ソリッドステートドライブ）等の記憶装置を備える。１又は複数のプロセッサは、ＲＯＭあるいは記憶装置に格納された処理プログラムを読み出して実行することで制御部１４ｄを実現する。キーボード等の入力装置が入力部１４ｂを実現し、ディスプレイ等の出力装置が表示部１４ｃを実現し、ＨＤＤ等の記憶装置が記憶部１４ｅを実現する。処理プログラムを実行することでプロセッサが実行する処理を例示すると、以下の通りである。
・テナントユーザ管理テーブル１４ｅ１を作成して記憶部１４ｅに記憶する
・ドメイン管理テーブル１４ｅ２を作成して記憶部１４ｅに記憶する
・入力部１４ｂから受け付けた統合ポリシーを用いて統合ポリシーテーブル１４ｅ３を作成して記憶部１４ｅに記憶する
・テナントが統合される場合に、テナントユーザ管理テーブル１４ｅ１、ドメイン管理テーブル１４ｅ２、及び統合ポリシーテーブル１４ｅ３を用いて統合後のテナントに属するユーザのセキュリティレベルを設定する
・統合後のテナントについて、テナントユーザ管理テーブル１４ｅ１、ドメイン管理テーブル１４ｅ２を更新して記憶部１４ｅに記憶する
【００３５】
図２Ａ及び図２Ｂは、管理サーバ１４の処理を模式的に示す。
【００３６】
テナントＡ１０に属するユーザとして、
ユーザｕ１、ユーザｕ２、ユーザｕ３
が存在するものとし、テナントＡ１０のドメインには、
aaa.fujixerox.co.jp
bbb.fujixerox.co.jp
が存在し、それぞれのドメインの認証レベルは、
aaa.fujixerox.co.jp：高
bbb.fujixerox.co.jp：低
であるとする。各ユーザのドメインは、例えば、
ユーザｕ１：u1@aaa.fujixerox.co.jp
ユーザｕ２：u2@ bbb.fujixerox.co.jp
ユーザｕ３：u3@dom.example.com
であるとすると、ユーザｕ１は認証レベルの高い認証済ユーザであり、ユーザｕ２は認証レベルの低い認証済ユーザであり、ユーザｕ３は未認証のゲストとなる。
【００３７】
他方、テナントＢ１２に属するユーザとして、
ユーザｕ４、ユーザｕ５、ユーザｕ６
が存在するものとし、テナントＢ１２のドメインには、
ccc.fujixerox.co.jp
ddd.fujixerox.co.jp
が存在し、それぞれのドメインの認証レベルは、
ccc.fujixerox.co.jp：高
ddd.fujixerox.co.jp：低
であるとする。各ユーザのドメインは、例えば、
ユーザｕ４：u4@ccc.fujixerox.co.jp
ユーザｕ５：u5@ ddd.fujixerox.co.jp
ユーザｕ６：u6@dom.example.com
であるとすると、ユーザｕ４は認証レベルの高い認証済ユーザであり、ユーザｕ５は認証レベルの低い認証済ユーザであり、ユーザｕ６は未認証のゲストとなる。
【００３８】
テナントＡ１０とテナントＢ１２が統合、例えばテナントＡ１０がテナントＢ１２を吸収合併することで統合すると、図２Ｂに示すように、テナントとして統合後のテナントＡ１１のみが存在することになり、統合後のテナントＡ１１には、
ユーザｕ１、ユーザｕ２、ユーザｕ３、ユーザｕ４、ユーザｕ５、ユーザｕ６
が属することになる。ユーザｕ１、ｕ２、ｕ３は、元からテナントＡ１０に属するユーザであるから統合後のテナントＡ１１においてもそのセキュリティレベルをそのまま維持し得るが、統合対象のテナントＢ１２に属していたユーザｕ４、ｕ５、ｕ６については、統合後のテナントＡ１１においてどのようにセキュリティレベルを設定するかが問題となる。例えば、ユーザｕ５については認証済ユーザであるもののその認証レベルは低いため、統合後のテナントＡ１１においてもそのまま認証済ユーザとして認めるとセキュリティ上問題となり得る。
【００３９】
管理サーバ１４の制御部１４ｄは、このような場合に、テナントユーザ管理テーブル１４ｅ１、ドメイン管理テーブル１４ｅ２、及び統合ポリシーテーブル１４ｅ３を参照し、ユーザ毎の認証レベルに応じ、統合ポリシーテーブル１４ｅ３で規定された統合ポリシー（あるいは統合ルール）に従って統合対象であるテナントＢ１２に属していたユーザのセキュリティレベルを設定する。
【００４０】
図３は、テナントユーザ管理テーブル１４ｅ１の一例を示す。テナントユーザ管理テーブル１４ｅ１は、各テナントに属するユーザのユーザＩＤ、セキュリティレベル及び認証ドメインを管理する。例えば、テナントＡ１０については、ユーザＩＤとして、
u1@aaa.fujixerox.co.jp
u2@ bbb.fujixerox.co.jp
u3@dom.example.com
が登録され、それぞれのセキュリティレベル及び認証ドメインは、
u1@aaa.fujixerox.co.jpのセキュリティレベル：認証済ユーザ
u1@aaa.fujixerox.co.jpの認証ドメイン：aaa.fujixerox.co.jp
u2@ bbb.fujixerox.co.jpのセキュリティレベル：認証済ユーザ
u2@ bbb.fujixerox.co.jpの認証ドメイン：bbb.fujixerox.co.jp
u3@dom.example.comのセキュリティレベル：ゲスト
u3@dom.example.comの認証ドメイン：なし
として登録される。テナントＢ１２については、ユーザＩＤとして、
u4@aaa.fujixerox.co.jp
u5@ bbb.fujixerox.co.jp
u6@dom.example.com
が登録され、それぞれのセキュリティレベル及び認証ドメインは、
u4@ccc.fujixerox.co.jpのセキュリティレベル：認証済ユーザ
u4@ccc.fujixerox.co.jpの認証ドメイン：ccc.fujixerox.co.jp
u5@ ddd.fujixerox.co.jpのセキュリティレベル：認証済ユーザ
u5@ ddd.fujixerox.co.jpの認証ドメイン：ddd.fujixerox.co.jp
u6@dom.example.comのセキュリティレベル：ゲスト
u6@dom.example.comの認証ドメイン：なし
として登録される。このテナントユーザ管理テーブル１４ｅ１を参照することで、テナントに属するユーザのセキュリティレベル及び認証ドメインを一義的に特定し得る。
【００４１】
図４は、ドメイン管理テーブル１４ｅ２の一例を示す。ドメイン管理テーブル１４ｅ２は、各テナントの認証ドメインを管理する。例えば、テナントＡ１０については、認証ドメインとして
aaa.fujixerox.co.jp
bbb.fujixerox.co.jp
が登録され、それぞれの認証ドメインの認証方法及び認証レベルは、
aaa.fujixerox.co.jpの認証方法：オンライン確認はＤＮＳ（Domain Name System）、人手による確認は確認済
aaa.fujixerox.co.jpの認証レベル：高
bbb.fujixerox.co.jpの認証方法：オンライン確認は未認証、人手による確認は確認済
bbb.fujixerox.co.jpの認証レベル：低
として登録される。テナントＢ１２については、認証ドメインとして
ccc.fujixerox.co.jp
ddd.fujixerox.co.jp
が登録され、それぞれの認証ドメインの認証方法及び認証レベルは、
ccc.fujixerox.co.jpの認証方法：オンライン確認はＷｅｂ、人手による確認は確認済
ccc.fujixerox.co.jpの認証レベル：高
ddd.fujixerox.co.jpの認証方法：オンライン確認はＤＮＳ、人手による確認は未確認
ddd.fujixerox.co.jpの認証レベル：低
として登録される。
【００４２】
ここで、認証レベルは、オンライン確認と人手による確認の程度に応じて決定される。すなわち、オンライン確認と人手による確認の二重確認の場合には認証レベルは高とされ、オンライン確認と人手による確認のいずれかの確認に留まる場合には認証レベルは低とされる。従って、例えば認証ドメインのaaa.fujixerox.co.jpについては、オンライン確認と人手による確認の二重確認であるため認証レベルは高とされる。
【００４３】
なお、ドメインの認証、すなわち実在性の確認については、以下の通りである。
【００４４】
テナントの運用母体である組織及びそのドメインの実在性を確認する方法として、実際にそのドメインの管理者でなければ設定することができないパブリックなリポジトリを利用してオンラインで確認する方法がある。また、人手を介して登記簿や第三者データベースの登録内容を確認したり、管理者の実在性を電話で直接確認する方法がある。
【００４５】
図５は、オンラインによる実在性の確認方法を模式的に示す。
【００４６】
＜第１ステップ＞
管理者１００は、ネットワークを介してテナントＡ１０に対し、ドメインaaa.fujixerox.co.jpの所有者確認を依頼する。
【００４７】
＜第２ステップ＞
テナントＡ１０は、この依頼に対し、チャレンジコードを返却する。例えば、チャレンジコードとして「challenge-201800023」を返却する。
【００４８】
＜第３ステップ＞
管理者１００は、テナントＡ１０から取得したチャレンジコードを、パブリックなリポジトリの該当する名前空間に登録する。例えば、ＤＮＳ１８に、aaa.fujixerox.co.jp IN TXT “challenge-201800023”と登録し、あるいはＷｅｂ２０にhttp:www.aaa.fujixerox.co.jp/index.html <meta challenge-201800023”と登録する。
【００４９】
＜第４ステップ＞
パブリックなリポジトリに登録された当該チャレンジコードを確認することで実在性を確認する。すなわち、ＤＮＳ１８あるいはＷｅｂにアクセスしてチャレンジコードを確認することでテナントＡ１０の実在性を確認する。
【００５０】
図６は、オンライン確認及び人手による確認を組み合わせたドメイン認証レベルを示す。上述したように、オンライン確認と人手による確認の二重確認の場合には認証レベルは高に設定され、オンライン確認と人手による確認のいずれかの確認の場合には認証レベルは低に設定される。なお、オンラインでも人手でも確認できない場合には未認証となる。また、ユーザのセキュリティレベル（信頼度）は、そのユーザの属するドメインの認証レベルに応じて決定される。すなわち、
ドメイン認証レベルが高→認証済ユーザ
ドメイン認証レベルが低→認証済ユーザ
ドメイン未認証→ゲスト
である。
【００５１】
図７は、統合ポリシーテーブル１４ｅ３の一例を示す。統合ポリシーテーブル１４ｅ３は、テナントＡ１０とテナントＢ１２を統合する場合に、ユーザのセキュリティレベルをどのように設定するかのルールを規定する。具体的には、統合ポリシーテーブル１４ｅ３は、統合前のユーザの属するドメイン認証レベルと、統合後の当該ユーザのセキュリティレベルとの対応関係を規定する。例えば、
ドメイン認証レベルが高→認証済ユーザ
ドメイン認証レベルが低→ゲスト
ドメイン未認証→ゲスト
である。図６では、
ドメイン認証レベルが低→認証済ユーザ
であるのに対し、図７では
ドメイン認証レベルが低→ゲスト
である点に留意されたい。これは、統合対象であるテナントに属するユーザの認証レベルが相対的に低い場合に、統合後のテナントではそのままの認証レベルを維持するのではなく、実質的に未認証に等しくゲストとして取り扱うことを意味する。
【００５２】
図８Ａは、本実施形態の処理フローチャートを示す。管理サーバ１４の制御部１４ｄで実行される処理であり、テナントＡ１０がテナントＢ１２を吸収合併することで統合する場合である。
【００５３】
テナントＡ１０及びテナントＢ１２が統合される場合、制御部１４ｄは、記憶部１４ｅに記憶されたテナントユーザ管理テーブル１４ｅ１にアクセスし、統合対象テナントに属するユーザのレコードを取得する（Ｓ１０１）。具体的には、統合対象テナントはテナントＢ１２であり、テナントＢに属するユーザのレコードとして、
u4@ccc.fujixerox.co.jpのセキュリティレベル：認証済ユーザ、認証ドメイン：ccc.fujixerox.co.jp
u5@ ddd.fujixerox.co.jpのセキュリティレベル：認証済ユーザ、認証ドメイン：ddd.fujixerox.co.jp
u6@dom.example.comのセキュリティレベル：ゲスト、認証ドメイン：なし
の各レコードを取得する。
【００５４】
次に、制御部１４ｄは、レコードが存在するか否かを判定する（Ｓ１０２）。統合対象のテナントに属するユーザが存在せず、そのレコードも存在しない場合には（Ｓ１０２でＮＯ）、図８Ｂの処理に移行する。
【００５５】
他方、レコードが存在する場合（Ｓ１０２でＹＥＳ）、制御部１４ｄは、取得したレコードを参照してユーザの認証ドメインを特定し、さらにドメイン管理テーブル１４ｅ２を参照してその認証ドメインに該当する認証レベルを特定する（Ｓ１０３）。
【００５６】
次に、制御部１４ｄは、統合ポリシーテーブル１４ｅ３を参照してユーザの認証ドメインの認証レベルに該当する統合後のセキュリティレベルを特定する（Ｓ１０４）。
【００５７】
そして、制御部１４ｄは、セキュリティレベルを特定すると、特定したセキュリティレベルでユーザのレコードを更新する（Ｓ１０５）。すなわち、テナントユーザ管理テーブル１４ｅ１における当該ユーザのテナントＩＤ、ユーザＩＤ、及びセキュリティレベルを更新する。また、テナントＢ１２は統合により消滅することから、制御部１４ｄは、ドメイン管理テーブル１４ｅ２からテナントＢ１２を削除する。
【００５８】
テナントユーザ管理テーブル１４ｅ１、ドメイン管理テーブル１４ｅ２、及び統合ポリシーテーブル１４ｅ３の参照方法は、要約すると以下の通りである。
（１）テナントユーザ管理テーブル１４ｅ１を参照して統合対象のユーザのユーザＩＤ、認証ドメインを特定する
（２）ドメイン管理テーブルを参照して当該ユーザの認証ドメインの認証レベルを特定する
（３）統合ポリシーテーブルを参照して当該ユーザの統合後のセキュリティレベルを特定する
（４）当該ユーザの特定後のセキュリティレベルを用いてテナントユーザ管理テーブル１４ｅ１及びドメイン管理テーブル１４ｅ２を更新する。
【００５９】
図８Ｂは、統合対象テナントであるテナントＢ１２に属するユーザのレコードがテナントユーザ管理テーブル１４ｅ１に存在しない場合（Ｓ１０２でＮＯ）の処理フローチャートである。
【００６０】
制御部１４ｄは、ドメイン管理テーブル１４ｅ２を参照して、統合対象テナントに属するドメインのレコードを取得する（Ｓ１０６）。具体的には、統合対象のテナントであるテナントＢ１２に属するドメインとして、
ccc.fujixerox.co.jp
ddd.fujixerox.co.jp
が存在するから、これらのレコードを取得する。そして、レコードが存在するか否かを判定し（Ｓ１０７）、存在しなければ処理を終了する。
【００６１】
レコードが存在する場合（Ｓ１０７でＹＥＳ）、制御部１４ｄは、統合ポリシーテーブル１４ｅ３を参照して、ドメインの認証レベルに該当する統合後のセキュリティレベルを特定する（Ｓ１０８）。
【００６２】
そして、特定したセキュリティレベルが認証済ユーザであるか否かを判定する（Ｓ１０９）。認証済ユーザであれば当該ドメインのレコードを更新し（Ｓ１１０）、認証済みユーザでない、つまり未認証であれば当該ドメインのレコードを削除する（Ｓ１１１）。
【００６３】
図９は、図８Ａ及び図８Ｂの処理により更新されたテナントユーザ管理テーブル１４ｅ１の一例を示す。元からテナントＡ１０に属していたユーザｕ１、ｕ２、ｕ３のレコードはそのまま維持されるが、統合対象のテナントＢ１２に属していたユーザｕ４，ｕ５、ｕ６のレコードは更新される。すなわち、ユーザｕ４、ｕ５、ｕ６のテナントＩＤはテナントＢからテナントＡに更新され、セキュリティレベルも更新される。ユーザｕ４のセキュリティレベルは認証済ユーザのままであるが、ユーザｕ５のセキュリティレベルは認証済ユーザからゲストに更新され、認証ドメインもなしに更新される。従って、ユーザｕ５は、統合前のテナントＢ１２においては認証済ユーザとしての利用権限を有していたが、統合後においては認証済ユーザとしての利用権限をもはや有しておらず、ゲストとして利用するためのより厳しい認証を経てデバイスを利用することになる。より厳しい認証には、認証済ユーザにのみ利用が許可されるデバイスについて利用不可となる場合も含まれ得る。ユーザｕ６のセキュリティレベルはゲストのまま維持される。
【００６４】
図１０は、図８Ａ及び図８Ｂの処理により更新されたドメイン管理テーブル１４ｅ２の一例を示す。認証ドメインccc.fujixerox.co.jpについてはテナントＢからテナントＡに更新される。また、認証ドメインddd.fujixerox.co.jpについては、図９に示されるように統合後のテナントＡには存在していないことから、当該ドメインのレコードは削除される。図において、×印は削除されて存在しないことを示す。
【００６５】
図１１は、本実施形態における統合ポリシーを用いた統合処理を模式的に示す。統合対象であるテナントＢ１２に属するユーザｕ４、ユーザｕ５、ユーザｕ６を統合後のテナントＡ１１に移行させる際に、統合のルールを規定した統合ポリシーを参照して移行させ、ユーザｕ４、ｕ５、ｕ６のセキュリティレベルを設定する。統合後のセキュリティレベルは、統合前のテナントＢ１２における当該ユーザが属するドメインの認証レベルに依存して決定される（図７参照）。また、統合後のテナントＡ１１における認証ドメインも、統合ポリシーにより決定される。具体的には、統合前のテナントＢ１２において存在していた認証ドメインddd.fujixerox.co.jpは、統合後のテナントＡ１１ではそれに属するユーザが存在しないため認証ドメインとして存在しない。
【００６６】
本実施形態では、図７に示すような統合ポリシーテーブル１４ｅ３を用いているが、統合ポリシーは、統合後のテナントＡ１１を管理する管理者が任意に入力して設定し得る。
【００６７】
図１２は、他の統合ポリシーテーブル１４ｅ３の例を示す。統合ポリシーテーブル１４ｅ３は、統合前のユーザの属するドメイン認証レベルと、統合後の当該ユーザのセキュリティレベルとの対応関係を規定する。具体的には、
ドメイン認証レベルが高→認証済ユーザ
ドメイン認証レベルが低→認証済ユーザ
ドメイン未認証→ゲスト
である。テナントＡ１０とテナントＢ１２が対等合併により統合する場合に、テナントＢ１２に属するユーザにテナントＡ１０に属するユーザと対等の権限を付与するとき等に有効である。
【００６８】
図１３は、さらに他の統合ポリシーテーブル１４ｅ３の例を示す。統合ポリシーテーブル１４ｅ３は、統合前のユーザの属するドメイン認証レベルと、統合後の当該ユーザのセキュリティレベルとの対応関係を規定する。具体的には、
ドメイン認証レベルが高→ゲスト
ドメイン認証レベルが低→ゲスト
ドメイン未認証→ゲスト
である。テナントＡ１０がテナントＢ１２を吸収合併により統合する場合において、テナントＢ１２に属するユーザの権限を制限するとき等に有効である。
【００６９】
また、本実施形態では、統合対象テナントに属するユーザのセキュリティレベルを設定しているが、これに加えて、サービスの利用ライセンスの許可／不許可を設定してもよい。この場合、制御部１４ｄは、セキュリティレベル設定手段として機能するとともに、ライセンス設定手段として機能する。
【００７０】
図１４は、テナントユーザ管理テーブル１４ｅ１の他の例を示す。図３では、テナントユーザ管理テーブル１４ｅ１には、ユーザＩＤ、セキュリティレベル、及び認証ドメインを登録しているが、ここではさらにユーザＩＤに対応付けてサービスＩＤを登録する。具体的には、テナントＡ１０ではサービスＡを提供し、テナントＢ１２ではサービスＢを提供するものとし、ユーザｕ１及びユーザｕ２はサービスＡを利用可能であり、ユーザｕ４及びユーザｕ５はサービスＢを利用可能であるとする。
【００７１】
図１５は、管理サーバ１４の記憶部１４ｅに追加的に記憶される、サービス管理テーブル１４ｅ４の一例を示す。サービス管理テーブル１４ｅ４は、テナント毎の各サービスのライセンス数（上限）及びライセンス費消数を管理する。例えば、テナントＡ１０で提供されるサービスＡのライセンス数は１００、ライセンス費消数は２であり、テナントＢ１２で提供されるサービスＢのライセンス数は１００、ライセンス費消数は２である。なお、サービスＡのライセンス費消数が２であるのは、ユーザｕ１及びユーザｕ２にライセンスを付与しているからであり、サービスＢのライセンス費消数が２であるのは、ユーザｕ４及びユーザｕ５にライセンスを付与しているからである。
【００７２】
図１６は、統合ポリシーテーブル１４ｅ３の他の例を示す。統合ポリシーテーブル１４ｅ３は、統合後のユーザのセキュリティレベルを規定するとともに、サービスのライセンスの付与／不付与を規定する。
【００７３】
統合前のテナントＢ１２に属するユーザに着目すると、テナントＡ１０においてのみ提供されていたサービスＡについては、統合後についてもサービスＡについてライセンスを付与しない。このことは、テナントＢ１２に属するユーザのセキュリティレベルに依存しない。すなわち、セキュリティレベルが認証済ユーザの場合であってもゲストであってもサービスＡのライセンスを付与しない。なお、テナントＡ１０に属するユーザについては、元々サービスＡについての運用がそのまま維持されるため統合ポリシーテーブル１４ｅ３では規定されていない。
【００７４】
他方、テナントＢ１２において提供されていたサービスＢについては、統合後のテナントＡ１１においても提供されるが、ユーザ毎にライセンスの付与／不付与が異なる。すなわち、統合前のテナントＡ１０に属していたユーザについては、認証済ユーザはサービスＢのライセンスを付与し、ゲストはサービスＢのライセンスを付与しない。また、統合前のテナントＢ１２に属していたユーザについては、認証済ユーザはサービスＢのライセンスを付与し、ゲストはサービスＢのライセンスを付与しない。要約すると、統合前のテナントとは無関係に、統合後のセキュリティレベルに応じてサービスＢについてライセンスの付与／不付与を設定する。
【００７５】
図１７は、統合ポリシーを用いた統合処理に伴うサービスライセンスの処理を模式的に示す。統合対象であるテナントＢ１２に属するユーザｕ４、ユーザｕ５、ユーザｕ６を統合後のテナントＡ１１に移行させる際に、統合のルールを規定した統合ポリシーを参照して移行させ、ユーザｕ４、ｕ５、ｕ６のセキュリティレベル及びユーザｕ１〜ｕ６のサービスＢについてのライセンスの付与／不付与を設定する。
【００７６】
サービスＡについては、統合対象のテナントＢ１２に属しているユーザｕ４、ユーザｕ５、ユーザｕ６にはライセンスを付与しない。
【００７７】
サービスＢについては、統合後のセキュリティレベルに応じてライセンス付与／不付与が決定される。従って、統合後のセキュリティレベルが認証済ユーザであるユーザｕ１、ユーザｕ２にはサービスＢについてライセンスが付与され、ゲストであるユーザｕ３にはライセンスが付与されない。また、統合後のセキュリティレベルがゲストである（図１３参照）ユーザｕ４、ユーザｕ５、ユーザｕ６にはサービスＢについてライセンスは付与されない。
【００７８】
図１８は、統合後の更新されたテナントユーザ管理テーブル１４ｅ１を示す。テナントＩＤがテナントＢ１２でサービスＩＤがサービスＢであるレコードが削除され、かつ、テナントＩＤがテナントＡでサービスＩＤがサービスＢであるレコードが新たに追加される。サービスＢのユーザＩＤとして、ユーザｕ１及びユーザｕ２のＩＤが登録される。
【００７９】
図１９は、統合後の更新されたサービス管理テーブル１４ｅ４を示す。テナントＢのテナントＩＤはテナントＢからテナントＡに更新される。サービスＢのライセンスは、ユーザｕ１及びユーザｕ２のみに付与されるから、ライセンス費消数は２のまま維持される。仮に、ユーザｕ４にライセンスを付与した場合、サービスＢのライセンス費消数は３に更新される。
【００８０】
なお、テナント毎に管理者が存在する場合において、テナントの統合時にセキュリティレベル、及びサービスのライセンスの許可／不許可を設定する際に、管理者権限を処理してもよい。この場合、制御部１４ｄは、セキュリティレベル設定手段及びライセンス設定手段として機能するとともに、権限設定手段としても機能する。
【００８１】
図２０は、管理者権限を付加したテナントユーザ管理テーブル１４ｅ１の一例を示す。テナントＢで提供されるサービスＢは、ユーザｕ４及びユーザｕ５が管理者権限を有し、ユーザｕ６は一般ユーザ（管理者権限を有しない）である。
【００８２】
図２１は、この場合のサービス管理テーブル１４ｅ４の一例を示す。サービスＢのライセンス数（上限）は１００、ライセンス費消数は３である。ユーザｕ４、ユーザｕ５、及びユーザｕ６にライセンスが付与されているからである。
【００８３】
図２２は、この場合の統合ポリシーテーブル１４ｅ３の一例を示す。統合後のサービスＢについて、統合前のセキュリティレベルに応じてライセンスの付与／不付与及び管理者権限の付与／不付与を決定する。すなわち、元のテナントＡの認証済ユーザについてはライセンスを付与し、かつ管理者権限を付与する。元のテナントＡのゲストについてはライセンスを付与せず、かつ、管理者権限も当然ながら付与しない。元のテナントＢの認証済ユーザについてはライセンスを付与するが管理者権限は付与せず一般ユーザとし、元のテナントＢのゲストについてはライセンスを付与せず、かつ、管理者権限も当然ながら付与しない。
【００８４】
図２３は、統合後の更新されたテナントユーザ管理テーブル１４ｅ１を示す。統合前のテナントＢのユーザｕ４及びユーザｕ５は、サービスＢについて管理者権限を有していたが、統合後では管理者権限を有さず一般ユーザとなる。ユーザｕ６についてはサービスＢのライセンスが付与されないため削除される。また、統合前のテナントＡのユーザｕ１及びユーザｕ２は、サービスＢについてライセンスが付与されると共に管理者権限が付与される。
【００８５】
図２４は、統合後の更新されたサービス管理テーブル１４ｅ４を示す。ユーザｕ４及びユーザｕ５は引き続きライセンスが付与され（但し、管理者権限を有しない）、ユーザｕ６はライセンスが付与されず、ユーザｕ１及びユーザｕ２に新たにライセンスが付与されたため、サービスＢのライセンス費消数は４に更新される。
【００８６】
以上、本発明の実施形態について説明したが、本発明はこれらの実施形態に限定されるものではなく、種々の変形が可能である。以下、変形例について説明する。
【００８７】
＜変形例１＞
実施形態では、図７の統合ポリシーテーブル１４ｅ３に示すように、ユーザのドメイン認証レベルに応じて統合後のテナントにおける当該ユーザのセキュリティレベルを設定しているが、これに加えてユーザのサービス使用頻度に応じてセキュリティレベルを設定してもよい。
【００８８】
例えば、図３に示すテナントユーザ管理テーブル１４ｅ１に、ユーザ毎にカウントされたサービスの使用頻度を登録し、サービスの使用頻度が相対的に大きい場合にはセキュリティレベルを相対的に上げる等である。これにより、ドメイン認証レベルとサービスの使用頻度に応じてセキュリティレベルが設定されることになり、ドメイン認証レベルが相対的に低くても使用頻度が相対的に高いユーザについては認証済ユーザとし、ドメイン認証レベルが相対的に低く使用頻度も相対的に低いユーザについてはゲストとする等である。
【００８９】
図２５は、この場合の統合ポリシーテーブル１４ｅ３の一例を示す。ドメイン認証レベルと使用頻度のマトリクスで統合後のセキュリティレベルが設定される。ドメイン認証レベルが高い場合、使用頻度の高低によらずに認証済ユーザに設定される。ドメイン認証レベルが未認証の場合、使用頻度によらずにゲストに設定される。ドメイン認証レベルが低い場合、使用頻度に応じて認証済ユーザとゲストのいずれかに設定される。
【００９０】
＜変形例２＞
実施形態では、図１６の統合ポリシーテーブル１４ｅ３に示すように、テナントＢ１２に属していたユーザがたとえ認証済ユーザであってもサービスＡのライセンスを付与していないが、統合前のテナントによらず、認証済ユーザにはライセンスを付与し、ゲストには付与しないとしてもよい。
【００９１】
また、管理者権限についても同様に、統合前のテナントによらず、認証済ユーザであって管理者権限を有していたユーザにはそのまま管理者権限を付与してもよい。
【００９２】
＜変形例３＞
実施形態では、テナントＡ１０とテナントＢ１２が統合する場合について説明したが、統合されるテナント数に制限はなく、３つ以上のテナントが統合する場合も同様に適用し得る。
【００９３】
また、あるテナントが２つ以上に分割される場合には、統合ポリシーテーブル１４ｅ３に代えて、分割ポリシーを規定する分割ポリシーテーブルを入力部１４ｂから入力して記憶部１４ｅに記憶し、ドメインの認証レベルと分割ポリシーテーブルに従って分割後のテナントに属するユーザ毎にセキュリティレベルを設定し得る。
【００９４】
＜変形例４＞
実施形態では、入力部１４ｂから統合ポリシーを入力して統合ポリシーテーブル１４ｅ３として記憶部１４ｅ３に記憶しているが、ネットワーク１６に接続された管理者端末からネットワーク１６を介して管理サーバ１４に統合ポリシーを供給してもよい。この場合、管理者端末から統合ポリシーを受信する通信Ｉ／Ｆ１４ａが統合ポリシー設定手段として機能し得る。また、統合ポリシーテーブル１４ｅ３は、管理サーバ１４とは別のサーバに記憶されていてもよく、制御部１４ｄは、テナントＡ１０とテナント１２が統合される場合に、ネットワーク１６を経て当該別のサーバに記憶されている統合ポリシーテーブル１４ｅ３を参照してセキュリティレベル等を設定してもよい。すなわち、管理サーバ１４は単一のサーバである必要はなく、複数のサーバから構成し得る。
【符号の説明】
【００９５】
１０  テナントＡ、１１  統合後のテナント  １２  テナントＢ、１４  管理サーバ、１６  ネットワーク。
【図１】
2020038548.tif 000003
【図２Ａ】
2020038548.tif 000004
【図２Ｂ】
2020038548.tif 000005
【図３】
2020038548.tif 000006
【図４】
2020038548.tif 000007
【図５】
2020038548.tif 000008
【図６】
2020038548.tif 000009
【図７】
2020038548.tif 000010
【図８Ａ】
2020038548.tif 000011
【図８Ｂ】
2020038548.tif 000012
【図９】
2020038548.tif 000013
【図１０】
2020038548.tif 000014
【図１１】
2020038548.tif 000015
【図１２】
2020038548.tif 000016
【図１３】
2020038548.tif 000017
【図１４】
2020038548.tif 000018
【図１５】
2020038548.tif 000019
【図１６】
2020038548.tif 000020
【図１７】
2020038548.tif 000021
【図１８】
2020038548.tif 000022
【図１９】
2020038548.tif 000023
【図２０】
2020038548.tif 000024
【図２１】
2020038548.tif 000025
【図２２】
2020038548.tif 000026
【図２３】
2020038548.tif 000027
【図２４】
2020038548.tif 000028
【図２５】
2020038548.tif 000029