(57)【要約】  オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御する方法、その方法を行うように動作可能なコンピュータプログラム製品およびオペレーティングシステム。この方法は、システムの重要な変更を行うためのユーザからの要求を受信するステップと、このユーザがシステムの重要な変更を行うための適切な特権を有するかどうかを評価するステップと、有する場合、システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに、受信した要求を通知するステップと、要求されたシステムの重要な変更を実行する前に、少なくとも１人のさらなるユーザからの承認を待つステップとを含む方法を提供する。諸態様および諸実施形態は、危険な、または破壊的なコマンドを直接発行し、実行する単一ユーザの能力を取り除くことによって、コンピュータシステムのセキュリティを向上させる。
2015531517.tif 000002
【特許請求の範囲】
【請求項１】
オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御する方法であって、
システムの重要な変更を行うためのユーザからの要求を受信するステップと、
前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを評価するステップと、
有する場合、前記システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに前記受信した要求を通知するステップと、
前記要求されたシステムの重要な変更を実行する前に、少なくとも１人の前記さらなるユーザから承認を待つステップと
を含む、方法。
【請求項２】
前記ユーザおよび前記少なくとも１人のさらなるユーザの両方が、システム管理者特権を有する、請求項１に記載の方法。
【請求項３】
前記承認および実行が、前記要求の前記受信と非同期的に行われる、請求項１または請求項２に記載の方法。
【請求項４】
受信するステップ、評価するステップ、および通知するステップが、カーネル空間で実行される、請求項１から３のいずれか一項に記載の方法。
【請求項５】
受信するステップ、評価するステップ、および通知するステップが、ユーザ空間で実行される、請求項１から３のいずれか一項に記載の方法。
【請求項６】
受信するステップ、評価するステップ、および通知するステップが、前記オペレーティングシステムによって実行されるデーモンによって実行され、前記デーモンが、適切な特権を有する、請求項５に記載の方法。
【請求項７】
前記デーモンが、オペレーティングシステムのいかなる単一ユーザによっても変更不可能である、請求項６に記載の方法。
【請求項８】
前記システムの重要な変更が、重要なオペレーティングシステムレベルの操作を含む、請求項１から７のいずれか一項に記載の方法。
【請求項９】
オペレーティングシステムによって実行可能などの変更を、システムの重要な変更とみなすかを構成するステップを含む、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
オペレーティングシステムによって実行可能な各システムの重要な変更にセキュリティレベルを割り当てるステップと、前記割り当てられたセキュリティレベルに基づいて前記システムの重要な変更に通知および承認パラメータを関連付けるステップとを含む、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
少なくとも１人のさらなるユーザに通知するステップが、前記少なくとも１人のさらなるユーザに電子メールを送信するための手続きの開始、前記少なくとも１人のさらなるユーザにＳＭＳメッセージを送信するための手続きの開始、前記少なくとも１人のさらなるユーザにインスタントメッセージを送信するための手続きの開始、前記少なくとも１人のさらなるユーザに電話で連絡を取るための手続きの開始、前記少なくとも１人のさらなるユーザにポップアップメッセージを表示するための手続きの開始、のうちの１つまたは複数を含む、請求項１から１０のいずれか一項に記載の方法。
【請求項１２】
コンピュータで実行されるとき、請求項１から１１のいずれか一項の方法を行うように動作可能なコンピュータプログラム製品。
【請求項１３】
ユーザによって実行可能なシステムの重要な変更を制御するように動作可能なオペレーティングシステムであって、
システムの重要な変更を行うためのユーザからの要求を受信するように動作可能な要求受信論理と、
前記ユーザが前記システムの重要な変更を行うための適切な特権を有するかどうかを評価するように動作可能な特権評価論理と、
前記システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに、前記受信された要求を通知し、前記ユーザが前記システムの重要な変更を行うための適切な特権を有すると評価される場合、前記システムの重要な変更を行うように動作可能な通知論理と、
少なくとも１人の前記さらなるユーザからの承認を待った後に、前記要求されたシステムの重要な変更を実行するように動作可能な実行論理と
を含む、オペレーティングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御する方法、ならびにその方法を行うように動作可能なオペレーティングシステムおよびコンピュータプログラム製品に関する。
【背景技術】
【０００２】
コンピューティングシステムをより良く保護する必要がある。一般的にはシステム管理者が、システム内のデータおよびコードにアクセスすることができる。さらに、信頼できない、潜在的に悪意のあるソフトウェアが、システム上で動作する可能性があり、システム内のデータおよびコードへアクセスする可能性がある。
【０００３】
潜在的に悪意のあるまたは有害な変更が行われることに対してより回復力のあるセキュアシステムが技術的に有効であり、さらにまた実用および実行の観点から入手可能でなければならない。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
潜在的に悪意のあるまたは有害な変更に対して向上した回復力を有するオペレーティングシステムを提供することが望ましい。
【課題を解決するための手段】
【０００５】
第１の態様が、オペレーティングシステムのユーザによって実行可能なシステムの重要な変更を制御する方法であって、システムの重要な変更を行うためのユーザからの要求を受信するステップと、このユーザがシステムの重要な変更を行うための適切な特権を有するかどうかを評価するステップと、有する場合、システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに受信した要求を通知するステップと、要求されたシステムの重要な変更を実行する前に、少なくとも１人のさらなるユーザからの承認を待つステップとを含む方法を提供する。
【０００６】
例えばデータセンタに併置されたサーバによってホストされるコンピューティングシステムは、通常、サーバルームへの物理的アクセスが厳しく制限されているので、一般的に良く保護されている。オペレーティングシステムおよびそこで動作しているアプリケーションへのリモートアクセスもまた、一般的に、例えば、セキュアシェル（ＳＳＨ）またはリモートデスクトップセッションによって制御される。一般ユーザが、人であれ、ソフトウェアサービスであれ、コンピューティングシステムに対して潜在的に破壊的な変更を行う能力を有することのないようにする方法が存在する。
【０００７】
一般的には、システムに変更を行う実質的に無制限の力を有する特別なユーザが存在する。このユーザは、多くのオペレーティングシステムにおいて一般的に「スーパーユーザ」と呼ばれる。ＵＮＩＸ（登録商標）およびＵＮＩＸ系システムでは、スーパーユーザ（ルート）が、各ユーザのパーミッション（ｐｅｒｍｉｓｓｉｏｎ）を変更するように操作可能である。ユーザ「ルート」は、ファイルおよびコマンドへの無制限のアクセスができる。したがってスーパーユーザアクセスができる悪意のあるユーザまたはマルウェアが、システム内の任意のアクションを行う、例えば機密データを消去する、仮想マシンをシャットダウンする、またはシステム全体をシャットダウンするように操作可能となるおそれがある。真のスーパーユーザもまた、上述の危険なアクションを含む、同様の一連のアクションを行うように操作可能となる可能性もあり、たとえ意図せずに、または不注意にであっても、真のスーパーユーザがこれらのアクションを行うおそれがあることは理解されよう。このようなシナリオは、他のオペレーティングシステム、例えばＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）においても発生する可能性がある。
【０００８】
オペレーティングシステムは、一般的に、「最小特権」原則に従って機能し、これに従って、各ユーザ（スーパーユーザ以外）がプラットフォーム上の一部の利用可能なサービスのみを管理できるようにユーザアカウントを構成することが可能である。例えば、ユーザが、ウェブサーバの構成を変更し、これを再起動することができる特権を割り当てられることがあるが、このユーザは、他のサービスまたはシステム全体をシャットダウンすることができる十分な特権を持つことはできない、または割り当てられないことがある。ユーザが、サービスを構成する際に故意なくミスを犯す、または個人的な目的のためにサービスを故意に誤った構成とする（ｍｉｓｃｏｎｆｉｇｕｒｅ）可能性がある。
【０００９】
一般的なオペレーティングシステムのアクセス制御モデルは、ユーザがオペレーティングシステムの各サービスを管理できるようにするために、クエリがアクセス制御サブシステムに送信され、そのアクセス制御サブシステムから返される回答が、バイナリ応答の形式で返されるようなものである。ユーザは、サービスを管理する許可を与えられていることも、許可を与えられていないこともある。
【００１０】
許可を与えられたユーザによって行われる管理アクションは、それらのアクションがチェックされる必要なしに承認される。本明細書に記載する態様および実施形態は、許可を与えられたユーザによって行われるアクション、例えば重要なアクションが、適切な特権を有する１人または複数の他のユーザによる承認を必要とすることが可能であるような、したがって任意の変更がシステムによって適用される前に、新しい構成が、２人以上のユーザによって合意されるような、一般的なオペレーティングシステムアクセス制御モデルへの変更と関連する利点が存在する可能性がある。
【００１１】
このような仕組みは、システム管理者によるミスに起因するサーバの誤った構成が、顧客とのセキュリティレベルの合意に違反すること、または例えば顧客のデータのセキュリティおよびプライバシーに違反することにつながるおそれのあるデータセンタおよび／またはクラウドコンピューティングサーバで実装される場合、有用である可能性があることは理解されよう。
【００１２】
一般的な現代のオペレーティングシステムでは、ユーザに要求された操作を行う許可を与えるために、アクセス制御リスト（ＡＣＬ）が使用される。例えば、特定のファイルを読み取るおよび／またはこれに書き込むおよび／またはこれを実行する能力を与えられたユーザが、一般的に、その特定のファイルと関連するＡＣＬに定義されることになる。ファイルシステムは、ポータブルオペレーティングシステムインタフェース（Ｐｏｒｔａｂｌｅ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ：ＰＯＳＩＸ）ＡＣＬをサポートすることができ、これに従って、個々のユーザおよびグループに対する複数のアクセスルールが、システムにおいて各ファイルに対して指定されることが可能である。
【００１３】
知られているＡＣＬ実装では、スーパーユーザが存在し、そのスーパーユーザは、システム全体に対して無制限のパーミッションを有し、したがって、例えば任意のファイルを追加する、編集する、もしくは削除する、またはシステムで動作する任意のアプリケーションを起動する、停止する、もしくは再起動するなど、任意のアションを行うことができる。多くの場合スーパーユーザは、訓練を受けた、技能を持つ者であり、このスーパーユーザは、一般的にシステム管理者とも呼ばれる。このようなシステム管理者は、一般的にコンピュータシステムをサポートし、管理することを担当している。システム管理者は、一般的には、障害およびデータ損失率の低い保守を支援することができる訓練および経験を身に着けている。しかしながら、依然として人的エラーが発生する可能性があり、悪意のあるユーザまたはソフトウェアが、依然としてシステム上で破壊的に動作する可能性がある。
【００１４】
人的エラーに対処するために、システムまたはアプリケーションが、発行されたいかなる「重要な」コマンドも自動的にチェックするように動作可能とすることができる。システムまたはアプリケーションは、スーパーユーザに適切な警告メッセージを送信するように動作可能とすることができる。重要なコマンドに関する最終決定は、スーパーユーザによって行われることが可能であるが、スーパーユーザが、自発的に、または意図せずに、このような警告メッセージを無視する可能性があり、重要なコマンドがコミットされる可能性がある。例えば、特権昇格技法により、システムへのスーパーユーザアクセスができる悪意のあるユーザまたはソフトウェアの活動は、制御不可能であることは理解されよう。いくつかの再認証対抗手段が適用されることが可能であるが、多くの場合、これは手遅れとなる。
【００１５】
個々のアプリケーションまたはサービスに、ワークフローに基づく相互作用モデルが利用可能である場合もあり、このモデルでは構成変更はコミットされる前に他のユーザによって承認される必要がある。例えば、インターネット上でのウェブページの発行をサポートする様々なコンテンツ管理システム（ＣＭＳ）が、多くの場合、ウェブベースの編集システムの形式で利用可能である、このような機能性を有し、これに従ってユーザは、ウェブサイトへのいくつかの変更を準備することができるが、そうした変更は、ある他のユーザがこの変更を承認するまで決定とされない。しかしながら、一般的にこのようなワークフローは、本明細書に記載する態様および実施形態によって提案されるように、オペレーティングシステムの最も内側の機能レベルでは利用可能ではない。
【００１６】
第１の態様は、オペレーティングシステムおよび／またはオペレーティングシステムによって提供されるサービスのマルチ許可（ｍｕｌｔｉ−ａｕｔｈｏｒｉｚａｔｉｏｎ）またはマルチ承認（ｍｕｌｔｉ−ａｐｐｒｏｖａｌ）管理を提供する。したがって諸態様は、実際のまたは仮想のコンピューティングシステムへの潜在的に破壊的な変更を回避するための手段を提供することができる。諸態様および諸実施形態は、オペレーティングシステム（ＯＳ）を拡張して、２人以上の管理者が「重要な」アクションに同意することを求められた後にその変更がコミットされることを実施するアクセス制御モデルを提供する。重要なアクションとは、実装に応じて構成されることが可能であるが、一般的に、オペレーティングシステムおよびオペレーティングシステムによって提供される１つもしくは複数のサービスの構成に潜在的に破壊的な変更を行うことと関連するアクションである。
【００１７】
１つの実施形態によれば、ユーザの少なくとも１人および少なくとも１人のさらなるユーザが、システム管理者特権を有する。こうした管理者特権は、実質的にスーパーユーザ特権と同義であることがある。諸実施形態では、ユーザおよび少なくとも１人のさらなるユーザは、同じ特権を有する。したがって、ピア承認（ｐｅｅｒ  ａｐｐｒｏｖａｌ）が行われることが可能である。１つの実施形態によれば、ユーザおよび少なくとも１人のさらなるユーザの両方が、システム管理者特権を有する。したがって、システムの重要な変更にコミットするにはマルチ承認のピア承認が必要であることがある。提案されるまたは要求される変更が特に重要である場合、より多数のピアユーザが変更を承認することを求められることがある。
【００１８】
１つの実施形態によれば、承認および実行は、要求の受信と非同期的に行われる。したがって、いくつかの実施形態では、要求される動作または変更が、少なくとも１人のさらなるユーザによるその後の承認のために延期され、その第２のユーザは、提案されたシステムレベルの変更を、これが実行される前に、二重チェックすることができる。したがって、要求された変更を認証するまたは承認するために、要求中のユーザと少なくとも１人のさらなるユーザの両方の同期動作の必要はない。いくつかの実施形態によれば、要求される重要な変更ごとに、承認プロセスが行われなければならないこと、およびユーザによってシステムの重要な変更が要求されるたびに、そのクロスレビューが行われることは理解されよう。したがって、単一ユーザは、すでに要求したシステムの重要な変更に関してそのユーザがクロスレビューされたかどうかにかかわらず、システムの重要な変更を実行することはできない。諸実施形態は、非同期モードの動作を提供することができ、それに従ってユーザが管理アクション、またはシステムの重要なアクションを実行するまたは要求することができ、そのアクションの適用は、適切な特権を有する別のユーザがそのようなアクションを検討し、承認することができるまで延期される。各ユーザは、自身の資格情報を使用して、個別にログインして、システムの重要な変更を行う、および／または承認待ちの他者によって要求された変更を承認し、適用することができる。
【００１９】
１つの実施形態によれば、受信すること、評価すること、および通知することが、カーネル空間で実行される。諸態様および諸実施形態は、例えばアクセス制御リストの拡張として、カーネル空間で、または、ユーザ空間、例えば絶えず動作する変更不可能なデーモンによる実行で、実現されることが可能である。１つの実施形態によれば、受信すること、評価すること、および通知することが、ユーザ空間で実行される。１つの実施形態によれば、受信すること、評価すること、および通知することが、オペレーティングシステムによって実行されるデーモンによって実行され、このデーモンが、適切な特権を有する。１つの実施形態では、デーモンは、スーパーユーザ特権を有する。１つの実施形態によれば、デーモンは、オペレーティングシステムのいかなる単一ユーザによっても変更不可能である。デーモンの動作パラメータを変更することが望まれる場合、例えばシステムの重要な変更の所定のセットに対してシステムの重要なアクションをアップグレードする、または修正する、または追加する、または取り消すなど、デーモンの変更自体が、システムの重要な変更を含み、マルチユーザ承認システムを必要とする可能性があることは理解されよう。
【００２０】
１つの実施形態によれば、システムの重要な変更は、重要なオペレーティングシステムレベルの操作を含む。
【００２１】
１つの実施形態によれば、この方法は、オペレーティングシステムによって実行可能などの変更を、システムの重要な変更とみなすかを構成することを含む。オペレーティングシステムによるマルチ承認プロセスの対象となる可能性がある重要な操作またはプロセスの例は、例えば、仮想または実マシンをリブートまたはシャットダウンする、ファイルまたはプロセスパーミッションの変更、セキュリティ設定（例えば、ファイアウォールポリシー）への変更の適用、ネットワーク設定に変更を適用すること、別のユーザのものである他の機密データにアクセスすること、およびその他の同様のアクションを含む。諸態様および諸実施形態は、ネットワークアダプタ、ネットワーキングサービス、およびルーティングテーブルの再構成、ユーザの作成および削除、ユーザ特権の変更、シャットダウンまたはリブート操作を行うことなど、重要なオペレーティングシステムレベルの操作を保護するオペレーティングシステム内のマルチ承認ワークフローを可能にする。
【００２２】
１つの実施形態によれば、方法は、オペレーティングシステムによって実行可能な各システムの重要な変更にセキュリティレベルを割り当てることと、割り当てられたセキュリティレベルに基づいてシステムの重要な変更に通知および承認パラメータを関連付けることとを含む。したがって、高いセキュリティレベルを有するように決定されたこれらの変更は、変更がコミットされる前に、２人以上のさらなるユーザが承認することを必要とすることができる。変更が高いセキュリティレベルを有する場合、選ばれる通知方法は、次のログイン時に１人または複数のさらなるユーザへ通知するのではなく、テキストメッセージの開始など、より即時の形式の通知を含むことができる。通知および承認パラメータは、このように様々なタイプの重要なレベルのシステム変更に合わせるように構成されることが可能である。
【００２３】
１つの実施形態によれば、少なくとも１人のさらなるユーザに通知することは、少なくとも１人のさらなるユーザに電子メールを送信するための手続きの開始、少なくとも１人のさらなるユーザにＳＭＳメッセージを送信するための手続きの開始、少なくとも１人のさらなるユーザにインスタントメッセージを送信するための手続きの開始、少なくとも１人のさらなるユーザに電話で連絡を取るための手続きの開始、少なくとも１人のさらなるユーザにポップアップメッセージを表示するための手続きの開始、のうちの１つまたは複数を含む。したがって通知は、様々な方法の１つまたは複数で行われることが可能である。カーネル自体は、電子メールを送信するように動作可能ではないが、カーネル空間で実行される場合、カーネルが適切なユーザ空間のデーモンに承認を要求しているペンディングの変更要求を引き渡すように動作可能となるように、諸実施形態が動作可能であることが可能であり、デーモン自体は、変更要求を適切なユーザに通知するように動作可能であることは理解されよう。
【００２４】
第２の態様が、コンピュータ上で実行されるとき、第１の態様の方法を行うように動作可能なコンピュータプログラム製品を提供する。
【００２５】
第３の態様が、ユーザによって実行可能なシステムの重要な変更を制御するように動作可能なオペレーティングシステムを提供し、このオペレーティングシステムは、ユーザからの要求を受信して、システムの重要な変更を行うように動作可能な要求受信論理と、ユーザがシステムの重要な変更を行うための適切な特権を有するかどうかを評価するように動作可能な特権評価論理と、ユーザがシステムの重要な変更を行うための適切な特権を有すると評価される場合、システムの重要な変更を行うための適切な特権を有する少なくとも１人のさらなるユーザに、受信した要求を通知するように動作可能な通知論理と、少なくとも１人のさらなるユーザからの承認を待った後に要求されたシステムの重要な変更を実行するように動作可能な実行論理とを含む。
【００２６】
１つの実施形態によれば、ユーザの少なくとも１人および少なくとも１人のさらなるユーザが、システム管理者特権を有する。
【００２７】
１つの実施形態によれば、ユーザおよび少なくとも１人のさらなるユーザの両方が、システム管理者特権を有する。
【００２８】
１つの実施形態によれば、実行論理は、要求されたシステムの重要な変更を実行する前に、少なくとも１人のさらなるユーザからの非同期の承認を待つように動作可能である。
【００２９】
１つの実施形態によれば、受信、評価、および通知論理は、カーネル空間で動作する。
【００３０】
１つの実施形態によれば、受信、評価、および通知論理は、ユーザ空間で動作する。
【００３１】
１つの実施形態によれば、受信、評価、および通知論理が、オペレーティングシステムによって実行されるデーモンとして動作し、このデーモンが、適切な特権を有する。
【００３２】
１つの実施形態によれば、デーモンは、オペレーティングシステムのいかなる単一ユーザによっても変更不可能である。
【００３３】
１つの実施形態によれば、重要な変更は、重要なオペレーティングシステムレベルの操作を含む。
【００３４】
１つの実施形態によれば、オペレーティングシステムは、オペレーティングシステムによって実行可能などの変更を、システムの重要な変更とみなすかを構成するように動作可能な構成論理を含む。
【００３５】
１つの実施形態によれば、構成論理は、オペレーティングシステムによって実行可能な各システムの重要な変更にセキュリティレベルを割り当て、割り当てられたセキュリティレベルに基づいてシステムの重要な変更に通知および承認パラメータを関連付けるように動作可能である。
【００３６】
１つの実施形態によれば、通知論理は、少なくとも１人のさらなるユーザに電子メールを送信するための手続きの開始、少なくとも１人のさらなるユーザにＳＭＳメッセージを送信するための手続きの開始、少なくとも１人のさらなるユーザにインスタントメッセージを送信するための手続きの開始、少なくとも１人のさらなるユーザに電話で連絡を取るための手続きの開始、少なくとも１人のさらなるユーザにポップアップメッセージを表示するための手続きの開始、のうちの１つまたは複数によって、少なくとも１人のさらなるユーザに通知するように動作可能である。
【００３７】
さらなる特定の態様および好ましい態様は、添付の独立請求項および従属請求項に提示される。従属請求項の特徴は、必要に応じて、請求項に明示的に提示された組合せ以外の組合せで、独立請求項の特徴と組み合わせられることが可能である。
【００３８】
装置機構が、機能を提供するように動作可能であると述べられる場合、これは、その機能を提供する装置機構、またはその機能を提供するように適合されたもしくは構成された装置機構を含むことは理解されよう。
【００３９】
次に、添付の図面を参照して本発明の実施形態についてさらに説明する。
【図面の簡単な説明】
【００４０】
【図１】２人の管理者の承認プロセスの例を概略的に示す図である。
【図２】１つの実施形態に従った承認プロセスを概略的に示す承認シーケンス図である。
【図３】１つの実施形態に従った承認プロセスを概略的に示す承認シーケンス図である。
【発明を実施するための形態】
【００４１】
概要
実施形態をさらに詳細に説明する前に、まず概要を述べる。諸態様および諸実施形態は、オペレーティングシステム（ＯＳ）を拡張して、２人以上の管理者が「重要な」アクションに同意することを求められた後にその変更がコミットされることを実施するアクセス制御モデルを提供する。重要なアクションとは、実装に応じて構成されることが可能であるが、一般的に、オペレーティングシステムおよびオペレーティングシステムによって提供される１つもしくは複数のサービスの構成に潜在的に破壊的変更を行うことと関連するアクションである。
【００４２】
諸態様および諸実施形態は、ＯＳのマルチ許可またはマルチ承認管理を有するオペレーティングシステム、またはオペレーティングシステムアクセス制御サブシステムの直接機能として、ソフトウェアスタックの最下位レベルで利用できるサービスを提供する。言い換えれば、諸態様および諸実施形態は、あたかも複数の管理者を有するかのように動作し、重要な操作が実施される前に、管理者のうちの２人以上が重要な操作を相互に承認することを求められる、オペレーティングシステムを提供する。相互のマルチ承認プロセス自体は、操作またはプロセスを重要と定義するためにも使用されることが可能であることは理解されよう。
【００４３】
マルチレベルの承認方式が、例えば以下のような、様々な方法で実行されることが可能である：
・管理者１が管理者２の操作を承認する、およびその逆に管理者２が管理者１の操作を承認する、図１に概略的に示すような、２人の管理者の承認プロセス。
・管理者の操作が、もう１人の管理者によって承認されなければならない（単一承認）または２人以上の他の管理者の組合せによって承認されなければならない（マルチ承認）、ｎ人の管理者の承認プロセス。
【００４４】
オペレーティングシステムによるマルチ承認プロセスの対象となる可能性がある重要な操作またはプロセスの例は、例えば以下を含む：
・仮想または実マシンをリブートまたはシャットダウンする
・ファイルまたはプロセスパーミッションの変更
・セキュリティ設定（例えば、ファイアウォールポリシー）への変更の適用
・ネットワーク設定に変更を適用すること
・別のユーザのものである他の機密データにアクセスすること
【００４５】
諸態様および諸実施形態は、カーネル空間において例えばアクセス制御リストの拡張として、または、ユーザ空間において例えば絶えず動作する変更不可能なデーモンによる実行で、実現されることが可能である。
【００４６】
図２および３は、１つの実施形態に従った承認プロセスを概略的に示す承認シーケンス図である。
【００４７】
１つの実施形態によれば、適切な変更が、ＵＮＩＸシステムによって実装されて、マルチ承認システムを導入することが可能である。適切な変更は、終わりのない実行プロセス、例えば、ａｐｐｒｏｖａｌｄと呼ばれるデーモンを含むことができ、このデーモンは、特定の特徴および所有権を有する。
【００４８】
このような実施形態によれば、スーパーユーザ、ルートが、標準的なＵＮＩＸ定義の特権を保持し、完全な管理者特権を有するように構成された唯一のユーザである。しかしながら、１つの実施形態に従って、オペレーティングシステムインストール手続き後に、管理者ルートのログインが恒久的に、かつ強制的に無効にされる。ユーザ、ルートは、すでに承認デーモンを開始しており、ａｐｐｒｏｖａｌｄに特権を有するシステムと関連する唯一のユーザである。すなわち、ルートがａｐｐｒｏｖａｌｄデーモンを「所有」し、これを開始するおよび／または停止することができるシステムにおける唯一のユーザである。
【００４９】
図２および図３には、２つの考えられる承認シーケンスが示されている。図示した例によれば、所与のプロセス（ｐｒｏｃｅｓｓ）の「重要な」構成ファイル（ｐｒｏｃｅｓｓ．ｃｏｎｆ）が、システム管理者（例えば、管理者１（ａｄｍｉｎ＿１））によって変更されている。
【００５０】
しかしながら、ｐｒｏｃｅｓｓ．ｃｏｎｆは、「重要な」プロセスであるように事前に構成されているため、ａｐｐｒｏｖａｌｄデーモンのみが、システムへの恒久的変更をコミットするように動作可能である。言い換えれば、コミットプロセスは、管理者１（ａｄｍｉｎ＿１）によって提案された変更にさらなるチェックが行われることを必要とする。図示した例に従って、承認デーモンは、変更がコミットされることが可能となる前に必要とされるさらなるチェックが、第２のシステム管理者（例えば、管理者２（ａｄｍｉｎ＿２））によるチェックおよび承認を含むように動作する。
【００５１】
いくつかの実施形態によれば、以下により詳細に説明し、図２および３に示すように、手続きが実行されることが可能である。
１．管理者１（ａｄｍｉｎ＿１）が、（例えば、新しいｐｒｏｃｅｓｓ．ｃｏｎｆを保存する、またはプロセスを再起動することによって）ｐｒｏｃｅｓｓ．ｃｏｎｆ上で行われた変更をコミットしようとするとき、ａｐｐｒｏｖａｌｄデーモンは、このような要求を通知される。例えば、図２および図３において、テキストエディタは、ＣＯＭＭＩＴ＿ＲＥＱ（＜ユーザ＞，＜ファイル＞）コマンドをａｐｐｒｏｖａｌｄに送信する。
２．デーモンａｐｐｒｏｖａｌｄは、管理者２（ａｄｍｉｎ＿２）に、任意の好適な通知方法（例えば、電子メール、インスタントメッセージング、ＳＭＳ、事前に録音された通話、ポップアップメッセージ）を用いて、ｐｒｏｃｅｓｓ．ｃｏｎｆに変更が提案されたことを通知する。
３．デーモンａｐｐｒｏｖａｌｄは、このようなＣＯＭＭＩＴ＿ＲＥＱ要求を、ＡＰＰＲＯＶＡＬ＿ＲＥＱ（＜ユーザ＞，＜ファイル＞）として管理者２（ａｄｍｉｎ＿２）に転送する。ＡＰＰＲＯＶＡＬ＿ＲＥＱは、別個のメッセージの部分とするか、通知メッセージ自体に組み込まれることが可能である。
４．結果として、管理者２（ａｄｍｉｎ＿２）が、管理者１（ａｄｍｉｎ＿１）によって行われた変更をチェックすることになり、変更は承認される（図２）か、却下される（図３）可能性がある。ａｐｐｒｏｖａｌｄへのこれらの承認された／却下されたというメッセージは、それぞれＡＰＰＲＯＶＡＬ＿ＡＣＫおよびＡＰＰＲＯＶＡＬ＿ＲＥＪで表されている。
５．最終的に、ａｐｐｒｏｖａｌｄが、ｐｒｏｃｅｓｓ．ｃｏｎｆへの提案された変更について行われた決定を、（例えば直接に、またはテキストエディタを介して）管理者１（ａｄｍｉｎ＿１）に通知する。
【００５２】
諸態様は、管理者エラー率を削減し、例えば攻撃者によって、またはマルウェアによって行われるスーパーユーザ攻撃によって引き起こされる可能性のある損害を著しく小さくすることができる。
【００５３】
諸態様および諸実施形態は、危険な、または破壊的なコマンドを直接発行する管理者の能力を取り除くことによって、コンピュータシステムのセキュリティを向上させる。
【００５４】
様々な上述の方法の諸ステップは、プログラムを組み込まれたコンピュータによって行われることが可能であることを、当業者は容易に理解するであろう。本明細書では、いくつかの実施形態はまた、例えばデジタルデータ記憶媒体など、プログラム記憶装置を含むものとし、これはマシンまたはコンピュータ可読であって、命令のマシン実行可能またはコンピュータ実行可能プログラムをエンコードし、前記命令が前記上述の方法のステップの一部または全部を行う。プログラム記憶装置は、例えば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハードドライブ、または光学式可読デジタルデータ記憶媒体であることが可能である。諸実施形態はまた、上述の方法の前記諸ステップを実行するようにプログラムされたコンピュータを含むものと意図されている。
【００５５】
「プロセッサ」または「ロジック」と呼ばれるいかなる機能ブロックも含む、図に示した様々な要素の機能は、専用のハードウェア、ならびに適切なソフトウェアと関連してソフトウェアを実行することができるハードウェアを使用することによって提供されることが可能である。プロセッサによって提供されるとき、機能は、単一の専用プロセッサによって、単一の共有プロセッサによって、またはその一部を共有することができる複数の個々のプロセッサによって、提供されることが可能である。さらに、「プロセッサ」または「コントローラ」または「ロジック」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアのみを指すと解釈されるべきではなく、暗黙的に、デジタル信号プロセッサ（ＤＳＰ）のハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するリードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発記憶装置を含むことがあるが、これらには限定されない。従来型および／またはカスタム型の他のハードウェアもまた含むことがある。同様に、図に示したいかなるスイッチも、単に概念上のものである。これらの機能は、プログラム論理の動作によって、専用論理によって、プログラム制御と専用論理の相互作用によって、または手動でさえも実行することができ、特定の技術は、状況からより具体的に理解されるので実装者によって選択可能である。
【００５６】
本明細書のいかなるブロック図も本発明の原理を具体化する例示的回路の概念図を表すことは、当業者には理解されよう。同様に、いかなるフローチャート、流れ図、状態遷移図、擬似コードなども、コンピュータまたはプロセッサが明示的に示されているかどうかにかかわらず、実質的にコンピュータ可読媒体に表現され、コンピュータまたはプロセッサによってそのように実行されることが可能な様々なプロセスを表すことは理解されよう。
【００５７】
説明および図面は、本発明の原理を示すにすぎない。したがって、本明細書には明示的に記載または表示されていないが、本発明の原理を具体化し、本発明の趣旨および範囲の内に含まれる様々な仕組みを当業者が案出することができるであろうと理解されよう。さらに、本明細書に列挙するすべての例は、原則として、発明者により当技術分野の促進に寄与される本発明の原理および概念を理解する際に読者の助けとなるように、単に教育的な目的であることを明らかに意図しており、このような具体的に列挙した例および条件に限定しないものであると解釈されたい。さらに、本発明の原理、態様、および実施形態、ならびにその特定の例を列挙する本明細書中のあらゆる記載は、その均等物を含むものとする。
【図１】
2015531517.tif 000003
【図２】
2015531517.tif 000004
【図３】
2015531517.tif 000005
【国際調査報告】
2015531517.tif 000006
2015531517.tif 000007