ユーザのロールはアプリケーション・リソースを使用することでエスカレートできるため、それらのリソースには動的に推移する承認のニーズを満たすメカニズムが用意されています。アプリケーションの特権のエスカレーションを実行するには、以下の操作を実行します。
ユーザ・ベースのセキュリティおよびアプリケーション・ベースのセキュリティ
インターシステムズのセキュリティ・モデルでは、ユーザ・ベース、アプリケーション・ベース、または両方をベースにした柔軟な特権の割り当てが可能です。アプリケーションの使用を特定のユーザのみに限定できるほか、すべてのユーザが使用できるようにすることもできます。アプリケーションの使用を承認されているユーザに対するそのアプリケーションの動作として、次の複数の動作が可能です。
-
ユーザの特権のみでアプリケーションを実行できます。
-
アプリケーションで一部のユーザの特権をエスカレートすることができます (マッチングロールとターゲット・ロールを使用)。
-
アプリケーションですべてのユーザの特権をエスカレートすることができます (アプリケーション・ロールを使用)。
-
一部の特権については、アプリケーションですべてのユーザに対してエスカレーションを発生させ、他の特権については特定のユーザに対してのみエスカレーションを発生させることができます (マッチングロール/ターゲット・ロールとアプリケーション・ロールを組み合わせて使用)。
このように、アプリケーションの使用を、特定のユーザのみに限定して認めるか、すべてのユーザに認めるか制御できます。また、アプリケーションをユーザの特権で実行するか、アプリケーション自体の特権で実行するかも制御できます。これにより、InterSystems IRIS では以下のような極めて柔軟なモデルが実現します。
安全なアプリケーションの保護とエスカレーションのマトリックス
Privilege Level / Protection Level |
Public Application |
Restricted Application |
With User-Dependent Privileges |
1.どのユーザでもアプリケーションを実行できます。アプリケーションはユーザの特権で実行されます。 |
2.指定されたユーザのみがアプリケーションを実行できます。アプリケーションはユーザの特権で実行されます。 |
With Privilege Escalation |
3.どのユーザでもアプリケーションを実行できます。アプリケーションは、アプリケーション・ロールとマッチングロールを通して、(拡張された) アプリケーション特権で実行されます。 |
4.指定されたユーザのみがアプリケーションを実行できます。アプリケーションは、アプリケーション・ロールとマッチングロールを通して、(拡張された) アプリケーション特権で実行されます。 |
上記のテーブルで説明した各シナリオは、以下のようなさまざまな承認モデルで広く使用されています。
1.ユーザ依存の特権を持つパブリック・アプリケーション
このモデルは、認証されたすべてのユーザが使用できるアプリケーションを表します。このアプリケーションは実行しても追加の特権は付与しません。例えば、企業の連絡先データベースの場合、その企業全体のロールに属するユーザであれば、任意の社員の所属先電話番号と電子メール・アドレスを知ることができます。管理職は、社員の自宅電話番号を知ることができる上位の特権を保持しています。人事担当のスタッフは、すべてのレコードを閲覧および更新できる、さらに上位の特権を保持しています。このアプリケーションにはすべての社員がアクセスできますが、その動作は、アプリケーションを呼び出したときに各社員が既に持っている特権で決まります。つまり、アプリケーションそのものからロールが与えられるわけではありません。
2.ユーザ依存の特権を持つ制限アプリケーション
このモデルは、指定のロールに属するユーザのみが使用できるアプリケーションを表します。このアプリケーションは実行しても追加の特権は付与しません。例えば、時給制の社員を扱う給与アプリケーションでは、勤務時間数や時給などが表示されます。このアプリケーションを実行するユーザは、HourlyEmployee ロールまたは HourlyManager ロールのメンバであることが必要です。このアプリケーションを実行すると、どのロールが指定されたかがチェックされます。このチェックにより、HourlyEmployee ロールのメンバは自身のデータを閲覧できますが、それを編集することはできません。一方、HourlyManager ロールのメンバは、報告の目的でデータの閲覧と編集が可能です。HourlyEmployee ロールのメンバである社員は、このアプリケーションを実行して個人データが正しいかどうかを確認できます。ここで要求されるロールのメンバではない月給制の社員などの他の社員は、このアプリケーションは実行することもできません。
3.特権のエスカレーションを伴うパブリック・アプリケーション
このモデルは、認証されたすべてのユーザが使用できるアプリケーションを表します。このアプリケーションは、実行するとユーザが属するロールに基づいて特権をエスカレートします(特定のロールについてのみ、特権をエスカレートすることもできます)。例えば、学生が自身のレコードを確認および更新できるアプリケーションが、大学にあるとします。ここでは、どの学生も認証されたユーザであり、自身の連絡先情報を編集できます。この機能をサポートするために、アプリケーションにはエントリを編集するためのコードがあります。このコードでは、編集されているエントリが認証ユーザと一致しているかどうかが確認され、一致していれば、レコードを更新できるようにコード自身の特権がエスカレートされます。更新の終了後は、特権が元の状態に戻されます。ある学生が他の学生のレコードを更新しようとしても、このエントリの確認に失敗するので、特権のエスカレートが発生せず、更新も行われません。このアプリケーションでは、ユーザが学籍係の業務ロールのメンバであるかどうかも確認されます。そのメンバである場合は、さらに広範囲に情報を更新できます。
4.特権のエスカレーションを伴う制限アプリケーション
このモデルは、指定のロールに属するユーザのみが使用できるアプリケーションを表します。このアプリケーションは、ユーザが属するロールに基づいて特権をエスカレートします(特定のロールについてのみ、特権をエスカレートすることもできます)。例えば、病院の救急処置室に置かれたアプリケーションでは、現在救急治療を受けている患者のレコードを閲覧できる、特別に幅広い特権を担当の医師に与えることが考えられます。救急処置室では高い緊急性が発生する可能性があることから、この設定では、単純な巡回診療の場合よりも多くの情報を医師に提示できることが必要です。したがって、この場合は特権のエスカレートが発生します。