役割によるアクセス制御 (RBAC) は、通常はスーパーユーザーに限定されているタスクに対するユーザーアクセスを制御するセキュリティー機能です。RBAC では、プロセスやユーザーにセキュリティー属性を適用することで、スーパーユーザーの権限を複数の管理者に分けることができます。プロセス権管理は、「特権」を介して実装されます。ユーザー権管理は RBAC によって行われます。
プロセス権管理については、「特権 (概要)」を参照してください。
RBAC 関連の作業については、第 9 章役割によるアクセス制御の使用 (手順)を参照してください。
第 10 章役割によるアクセス制御 (参照)にも参考情報が挙げられています。
従来の UNIX システムでは、root ユーザー (スーパーユーザーとも呼ばれる) が全権を有します。root として実行されるプログラム、または setuid プログラムにも全権があります。root ユーザーは全ファイルの読み取り権とアクセス権、全プログラムの実行権を持ち、任意のプロセスに終了シグナルを送ることができます。実際、スーパーユーザーになるユーザーは、使用するサイトのファイアウォールの変更、監査トレールの変更、機密レコードの読み取り、ネットワーク全体の停止などを行えます。setuid プログラムがハイジャック (強奪) されると、システム上で何が起きても不思議はありません。
役割によるアクセス制御 (RBAC) は、絶対的なスーパーユーザーモデルに代わるより厳密な機密保護機能です。RBAC を使用することで、セキュリティーポリシーをきめ細かく適用できます。RBAC では、「最小特権」というセキュリティー原則が使用されます。最小特権は、ジョブを行う上で必要な特権だけをユーザーに与えることを意味します。通常のユーザーには、アプリケーションの実行、実行中のジョブの状態チェック、ファイルの出力、新しいファイルの作成などに必要なだけの特権が与えられます。通常のユーザー権限を超える権限は、権利プロファイルとしてグループ化されます。スーパーユーザー権限の一部が必要なジョブを行うユーザーは、適切な権利プロファイルを含む役割を引き受けます。
RBAC では、スーパーユーザー権限を「権利プロファイル」としてまとめます。これらの権利プロファイルは、「役割」と呼ばれる特殊なユーザーアカウントに割り当てられます。ユーザーは、スーパーユーザー権限の一部を必要とするジョブを行う場合に役割を引き受けることができます。Solaris ソフトウェアには、あらかじめ定義された権利プロファイルが用意されています。管理者は役割を作成し、プロファイルを割り当てます。
権利プロファイルを使用することで、さまざまな権限を提供できます。たとえば、Primary Administrator 権利プロファイルはスーパーユーザーと同等です。権限を限定して権利プロファイルを定義することもできます。たとえば、Cron Management 権利プロファイルは at ジョブと cron ジョブを管理します。役割を作成する場合は、多くの権限を持つ役割を作ることも、わずかな権限を持つ役割を作ることもできます。あるいはこの両方を作成することも可能です。
RBAC モデルでは、スーパーユーザーが 1 つ以上の役割を作成します。役割は、権利プロファイルに基づいて作成されます。続いてスーパーユーザーは、役割の作業に適したユーザーにその役割を割り当てます。ユーザーは、各自のユーザー名でログインします。ログイン後ユーザーは、限定された管理コマンドとグラフィカルユーザーインタフェース (GUI) ツールを実行できる役割を引き受けます。
役割は柔軟に設定できるため、さまざまなセキュリティーポリシーに対応できます。出荷時の Solaris オペレーティングシステム (Solaris OS) には役割は定義されていませんが、推奨の 3 つの役割は簡単に設定できます。これらの役割は、同じ名前の権利プロファイルに基づいています。次にこれらの役割を示します。
System Administrator – セキュリティーに関係のない管理作業を行う役割で、権限が限定されています。この役割ではファイルシステム、メール、ソフトウェアのインストールなどを管理できます。ただし、パスワードの設定は行えません。
これらの 3 つの役割の実装は必須ではありません。役割は、組織のセキュリティー要件に応じて設定する機能です。役割は、セキュリティー、ネットワーク、ファイアウォールの管理など、特定の目的の管理に合わせて設定できます。別の方法として、強力な管理者役割を 1 つと上級ユーザー役割を作成することもできます。この上級ユーザー役割は、自分のシステムの各部を修正することを認められたユーザーに割り当てます。
スーパーユーザーモデルと RBAC モデルは共存できます。次の表は、RBAC モデルで設定できる権限 (スーパーユーザーから制限された通常ユーザーまで) を順に挙げ、両モデルで監視できる管理アクションを示しています。システム上での特権の効果だけをまとめた情報としては、表 8–2 を参照してください。
表 8–1 スーパーユーザーモデルと特権を使用した RBAC モデルの比較
システムにおけるユーザー権限 |
スーパーユーザーモデル |
RBAC モデル |
---|---|---|
すべてのスーパーユーザー権限を持つスーパーユーザーになる |
はい |
はい |
すべてのユーザー権限を持つユーザーとしてログインする |
はい |
はい |
権限が限定されたスーパーユーザーになる |
いいえ |
はい |
ユーザーとしてログインし、散発的にスーパーユーザー権限を持つ |
可能 (setuid プログラムのみ) |
可能 (setuid プログラム、および RBAC を使用) |
すべてのスーパーユーザー権限ではなく、一部の管理権限だけを持つユーザーとしてログインする |
いいえ |
可能 (RBAC を使用、および直接割り当てられた特権と承認を使用) |
通常のユーザーよりも少ない権限を持つユーザーとしてログインする |
いいえ |
可能 (RBAC を使用、および特権を削除してログイン) |
スーパーユーザーの処理を監視する |
可能 (su コマンドを監査することによって監視) |
可能 (プロファイルシェルコマンドを監査することによって監視) root ユーザーが無効になっている場合には、root 役割を引き受けたユーザーの名前が監査トレールに入ります |
Solaris OS の RBAC モデルでは、次の要素が導入されました。
承認 – セキュリティーに影響を及ぼす可能性のあるアクション群をユーザーまたは役割が実行できるようにするアクセス権。たとえばインストール時には、セキュリティーポリシーによって solaris.device.cdrw 承認が通常のユーザーに与えられます。この承認によってユーザーは CD-ROM デバイスの読み取りと書き込みが行えます。承認の一覧は、/etc/security/auth_attr ファイルを参照してください。
特権 – コマンド、ユーザー、役割、またはシステムに与えることができる個別の権利。特権によってプロセスの正常実行が可能となります。たとえば、proc_exec 特権によってプロセスは execve() を呼び出すことができます。通常のユーザーには基本特権が与えられます。自分の基本特権を確認するには、ppriv -vl basic コマンドを実行します。
セキュリティー属性 – プロセス処理を可能にする属性。典型的な UNIX 環境では、通常のユーザーに禁止されているプロセス処理が、セキュリティー属性によって可能になります。たとえば、setuid プログラムと setgid プログラムはセキュリティー属性を持ちます。RBAC モデルでは、通常のユーザーが行う処理でセキュリティー属性が要求されることがあります。RBAC モデルでは、setuid プログラムや setgid プログラムだけでなく、承認と特権もセキュリティー属性です。たとえば、solaris.device.allocate 承認が与えられたユーザーは、デバイスを独占的に使用するためにそのデバイスの割り当てを行うことができます。sys_time 特権を持つプロセスは、システム時刻を操作できます。
特権付きアプリケーション – セキュリティー属性を確認することによってシステム制御に優先するアプリケーションまたはコマンド。典型的な UNIX 環境と RBAC モデルでは、setuid と setgid を使用するプログラムは特権付きアプリケーションです。RBAC モデルでは、処理を正常に実行する上で特権または承認を必要とするプログラムも特権付きアプリケーションです。詳細は、「特権付きアプリケーションと RBAC」を参照してください。
権利プロファイル – 役割またはユーザーに割り当てることができる管理権限の集まり。権利プロファイルには、承認から構成されるもの、セキュリティー属性を持つコマンドから構成されるもの、ほかの権利プロファイルから構成されるものがあります。権利プロファイルは、セキュリティー属性をグループ化する手段として便利です。
役割 – 特権付きアプリケーションを実行するための特殊な識別情報。この特殊な識別情報を取得できるのは、あらかじめ割り当てられたユーザーだけです。役割によって実行されるシステムではスーパーユーザーは不要です。スーパーユーザー権限はいくつかの役割に分散されます。たとえば、役割が 2 つ存在するシステムでは、セキュリティー作業をセキュリティー役割によって処理し、セキュリティー関連ではないシステム管理作業を他方の役割で処理できます。役割を細かく分割することも可能です。たとえば、暗号化フレームワーク、プリンタ、システム時刻、ファイルシステム、監査などをそれぞれ処理する個別の管理役割を作成できます。
次の図では、各 RBAC 要素の動作を示します。
RBAC では、ユーザーに役割が割り当てられます。役割を引き受けると、ユーザーはその役割の権限を利用できる状態となります。役割の権限は権利プロファイルから取得されます。権利プロファイルには、承認、特権付きコマンド、その他の補足的な権利プロファイルを含めることができます。特権付きコマンドは、セキュリティー属性を使用して実行されるコマンドです。
次の図は、Operator 役割、Operator 権利プロファイル、Printer Management 権利プロファイルを例に、RBAC 要素の関係を示しています。
Operator 役割は、プリンタ管理とメディアのバックアップを行うのに使用されます。この役割は、ユーザー jdoe に割り当てられています。jdoe は、この役割に切り替えて役割のパスワードを入力することにより、この役割を引き受けることができます。
Operator 権利プロファイルは、Operator 役割に割り当てられています。Operator 権利プロファイルには、2 つの補助プロファイル Printer Management と Media Backup が割り当てられています。これらの補助プロファイルは、Operator 役割の主要な作業を反映しています。
Printer Management 権利プロファイルは、プリンタ、印刷デーモン、およびスプーラの管理用プロファイルです。Printer Management 権利プロファイルには、 solaris.admin.printer.read、solaris.admin.printer.delete、および solaris.admin.printer.modify 承認が含まれています。これらの承認を使用することで、役割とユーザーはプリンタキューの情報を操作できます。Printer Management 権利プロファイルには、euid=lp が指定された /usr/sbin/lpshut、euid=0 が指定された /usr/ucb/lpq など、セキュリティー属性が指定された多数のコマンドも含まれます。
「承認」は、役割またはユーザーに許可できる個別の権限です。承認は、ユーザーアプリケーションレベルでポリシーを適用します。承認は、役割またはユーザーに直接割り当てることができます。一般に、承認は権利プロファイルに含められます。権利プロファイルは役割に含められ、役割がユーザーに割り当てられます。例については、図 8–2 を参照してください。
RBAC に準拠したアプリケーションは、ユーザーの承認を確認してから、アプリケーションまたはアプリケーション内の特定の操作に対するアクセス権を許可します。この承認の確認は、従来の UNIX アプリケーションが行なっていた UID=0 の確認に代わるものです。承認についての詳細は次の節で説明します。
特権は、カーネル内でセキュリティーポリシーを適用します。承認と特権の違いは、セキュリティーポリシーが適用されるレベルにあります。プロセスに適切な特権がないと、特権化された処理の実行がカーネルによって防止される可能性があります。適切な承認が与えられていないユーザーは、特権付きアプリケーションを使用できなかったり、特権付きアプリケーションに含まれるセキュリティーの厳しい処理を実行できなかったりする可能性があります。特権についての詳細は、「特権 (概要)」を参照してください。
システム制御に優先するアプリケーションとコマンドは、特権付きアプリケーションとみなされます。アプリケーションは、UID=0 のようなセキュリティー属性、特権、および承認によって特権化されます。
root (UID=0) やその他の特殊な UID または GID を確認する特権付きアプリケーションは、UNIX 環境に古くから存在します。権利プロファイルのメカニズムによって、特定の ID を必要とするコマンドを分離できます。任意のユーザーがアクセスできるコマンドの ID を変更する代わりに、実行セキュリティー属性を指定したコマンドとして権利プロファイルに配置できます。その権利プロファイルを持つユーザーまたは役割であれば、スーパーユーザー以外でもプログラムを実行できます。
ID として、実 ID または実効 ID を指定できます。実効 ID を割り当てた場合は、実 ID より優先されます。実効 ID は、ファイルアクセス権ビットの setuid 機能に相当します。実行 ID は、監査のために UID の識別も行います。ただし、root の実 UID を要求するシェルスクリプトやプログラムのために、実 ID も設定できます。たとえば、pkgadd コマンドは、実効 UID ではなく実 UID を要求します。コマンドを実行する上で実効 ID では十分でない場合は、ID を実 ID に変更する必要があります。手順については、「権利プロファイルを作成または変更する方法」を参照してください。
特権付きアプリケーションでは、特権の使用を確認できます。RBAC 権利プロファイルメカニズムを使用すれば、特定のコマンドに特権を指定できます。この方法では、アプリケーションまたはコマンドの実行時にスーパーユーザー権限を要求するのではなく、実行セキュリティー属性を指定してコマンドを権利プロファイルとして分離します。この権利プロファイルを持つユーザーまたは役割は、そのコマンドの実行に必要な特権だけを使用してコマンドを実行できます。
Kerberos コマンド (kadmin、kprop、kdb5_util など)
ネットワークコマンド (ifconfig、routeadm、snoop など)
ファイルコマンドとファイルシステムコマンド (chmod、chgrp、mount など)
プロセスを制御するコマンド (kill、pcred、rcapadm など)
コマンドに特権を指定して権利プロファイルに追加する方法は、「権利プロファイルを作成または変更する方法」を参照してください。特定のプロファイルに特権が存在するか確認するコマンドを調べる方法については、「割り当てられた特権の判断」を参照してください。
Solaris OS には、承認を確認するコマンドも用意されています。当然ながら、root ユーザーにはあらゆる承認が与えられます。このため、root ユーザーは任意のアプリケーションを実行できます。承認があるかどうかを確認するアプリケーションには次のようなものがあります。
Solaris 管理コンソールのすべてのツール
監査管理用のコマンド (auditconfig、auditreduce など)
プリンタ管理用のコマンド (lpadmin、lpfilter など)
バッチジョブ関連のコマンド (at、atq、batch、crontab など)
デバイス向けのコマンド (allocate、deallocate、list_devices、cdrw など)
承認の確認のためにスクリプトまたはプログラムをテストする方法については、例 9–24 を参照してください。承認が必要なプログラムの作成方法については、『Oracle Solaris セキュリティーサービス開発ガイド』の「承認について」を参照してください。
「権利プロファイル」は、役割またはユーザーに割り当てることができるシステムの設定より優先されるオペレーションの集合です。権利プロファイルには、承認、割り当て済みのセキュリティー属性が指定されたコマンド、その他の権利プロファイルを含めることができます。権利プロファイル情報は、prof_attr データベースと exec_attr データベースに分けて保存されます。権利プロファイル名と承認は、prof_attr データベースに置かれます。権利プロファイル名と、割り当て済みのセキュリティー属性が指定されたコマンドは、exec_attr データベースに置かれます。
権利プロファイルの詳細は、次の節を参照してください。
「役割」は、特権付きアプリケーションを実行できる特別な種類のユーザーアカウントです。役割は、ユーザーアカウントと同じ方法で作成され、ホームディレクトリ、グループ割り当て、パスワードなどを持ちます。権利プロファイルと承認は、役割に管理権限を与えます。役割は、ほかの役割やユーザーから権限を継承することはできません。個々の役割によってスーパーユーザー権限が分配されるため、安全な管理が行えるようになります。
ユーザーが役割を引き受けると、その役割の属性がすべてのユーザー属性を置き換えます。役割情報は、passwd、shadow、および user_attr データベースに保存されます。役割情報の追加は、audit_user データベースに対して行うことができます。役割の設定についての詳細は、次の節を参照してください。
各役割は、複数のユーザーに割り当てることができます。同じ役割になるすべてのユーザーは、同じ役割のホームディレクトリを持ち、同じ環境で動作し、同じファイルへのアクセス権を持ちます。ユーザーは、コマンド行から su コマンドを実行し、役割名とパスワードを指定して役割を引き受けることができます。Solaris 管理コンソールツールで役割を引き受けることもできます。
役割自体が直接ログインすることはできません。ユーザーがまずログインし、続いて役割を引き受けます。役割を引き受けたあとは、その役割を終了するまでほかの役割を引き受けることはできません。つまり、その役割を終了すれば、ほかの役割を引き受けることができます。
「root ユーザーを役割にする方法」に示しているように、root ユーザーを役割に変更することによって、匿名の root ログインを防ぐことができます。プロファイルシェルコマンド pfexec が監査の対象となっている場合、監査トレールにはログインユーザーの実 UID、そのユーザーが引き受けた役割、およびその役割が行ったアクションが記録されます。役割による処理を行うシステムまたは特定のユーザーを監査する方法については、「役割を監査する方法」を参照してください。
Solaris には、事前に定義された役割は用意されていません。ただし、ソフトウェアに付属している権利プロファイルは、役割に対応付けられています。たとえば、Primary Administrator 権利プロファイルを使用すると、Primary Administrator 役割を作成できます。
Primary Administrator 役割を設定する方法については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。
ほかの役割の設定方法については、「GUI を使用して役割の作成および割り当てを行う方法」を参照してください。
コマンド行で役割を作成する方法については、「RBAC の管理(作業マップ)」を参照してください。
役割は、特権付きアプリケーションを Solaris 管理コンソール起動ツールから実行することも、あるいは「プロファイルシェル」から実行することもできます。プロファイルシェルは、権利プロファイルに含まれるセキュリティー属性を認識する特殊なシェルです。プロファイルシェルは、ユーザーが su コマンドを実行して役割を引き受けたときに起動されます。プロファイルシェルには、pfsh、pfcsh、および pfksh があります。これらはそれぞれ、Bourne シェル (sh)、C シェル (csh)、および Korn シェル (ksh) に対応します。多くのシェルには、対応するプロファイルシェルが存在します。たとえば、Bourne シェル (sh)、C シェル (csh)、および Korn シェル (ksh) に対応するプロファイルシェルは、それぞれ pfsh、pfcsh、および pfksh です。プロファイルシェルのリストについては、pfexec(1) のマニュアルページを参照してください。
権利プロファイルが直接割り当てられたユーザーは、セキュリティー属性が指定されたコマンドを実行する場合、プロファイルシェルを起動する必要があります。操作性やセキュリティーに関する考慮事項については、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。
プロファイルシェルで実行されるコマンドはすべて、監査の対象に含めることができます。詳細は、「役割を監査する方法」を参照してください。
ネームサービススコープは、RBAC を理解する上で重要な概念です。役割の適用範囲は、個々のホストに限定されることもあれば、ネームサービス (NIS、NIS+、または LDAP) のサービス対象となるすべてのホストとなることもあります。システムにおけるネームサービススコープは、/etc/nsswitch.conf で指定します。検索は、最初に一致した時点で停止します。たとえば、権利プロファイルが 2 つのネームサービススコープに存在する場合、最初のネームサービススコープに含まれるエントリだけが使用されます。最初に一致したものが files の場合、役割の適用範囲はローカルホストに限定されます。
一般にユーザーは、役割を通して管理権限を取得します。承認と、特権付きコマンドは、権利プロファイル内でグループ化されます。権利プロファイルは役割に含められ、役割がユーザーに割り当てられます。
権利プロファイルとセキュリティー属性を直接割り当てることも可能です。
ユーザーには、権利プロファイル、特権、および承認を直接割り当てることができます。
役割には、特権と承認を直接割り当てることができます。
しかし、割り当てを直接行うことは安全とは言えません。特権が直接割り当てられたユーザーと役割は、カーネルがその特権を要求するどの場合でもセキュリティーポリシーに優先します。特権が権利プロファイルでコマンドのセキュリティー属性として指定される場合には、その特権はその権利プロファイルを持つユーザーによってそのコマンドでしか使用できません。そのユーザーまたは役割が実行するほかのコマンドでは使用できません。
承認はユーザーレベルで作用するため、承認の直接割り当ては特権の直接割り当てよりリスクが小さいと言えます。しかし、承認が与えられることでユーザーは高セキュリティーが求められる作業 (デバイス管理の委託など) でも実施できるようになります。
ユーザーに直接割り当てられた権利プロファイルでは、セキュリティーよりも操作性に関して問題が多く発生します。権利プロファイルでセキュリティー属性が指定されたコマンドは、プロファイルシェルでしか実行できません。ユーザーは、プロファイルシェルを開いてコマンドを入力する必要があります。権利プロファイルが割り当てられた役割は、プロファイルシェルを自動的に取得します。このため、コマンドはその役割のシェルで正常に実行されます。
権利プロファイルは、拡張性のある適切な手段として、特定の管理作業のセキュリティー特性をグループ化することができます。