ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
![]() |
Solaris のシステム管理: セキュリティーサービス Oracle Solaris 10 1/13 Information Library (日本語) |
パート II システム、ファイル、およびデバイスのセキュリティー
13. Oracle Solaris の暗号化フレームワーク (概要)
14. Oracle Solaris の暗号化フレームワーク (タスク)
24. Kerberos エラーメッセージとトラブルシューティング
26. Kerberos アプリケーションの使用 (タスク)
役割によるアクセス制御 (RBAC) は、通常はスーパーユーザーに限定されているタスクに対するユーザーアクセスを制御するセキュリティー機能です。RBAC では、プロセスやユーザーにセキュリティー属性を適用することで、スーパーユーザーの権限を複数の管理者に分けることができます。プロセス権管理は、「特権」を介して実装されます。ユーザー権管理は RBAC によって行われます。
プロセス権管理については、「特権 (概要)」を参照してください。
RBAC 関連のタスクについては、第 9 章役割に基づくアクセス制御の使用 (タスク)を参照してください。
第 10 章役割によるアクセス制御 (参照)にも参考情報が挙げられています。
従来の UNIX システムでは、root ユーザー (スーパーユーザーとも呼ばれる) が全権を有します。root として実行されるプログラム、または setuid プログラムにも全権があります。root ユーザーは全ファイルの読み取り権とアクセス権、全プログラムの実行権を持ち、任意のプロセスに終了シグナルを送ることができます。実際、スーパーユーザーになるユーザーは、使用するサイトのファイアウォールの変更、監査トレールの変更、機密レコードの読み取り、ネットワーク全体の停止などを行えます。setuid プログラムがハイジャック (強奪) されると、システム上で何が起きても不思議はありません。
役割に基づくアクセス制御 (RBAC) は、絶対的なスーパーユーザーモデルに代わるより厳密な機密保護機能です。RBAC を使用することで、セキュリティーポリシーをきめ細かく適用できます。RBAC では、「最小特権」というセキュリティー原則が使用されます。最小特権は、ジョブを行う上で必要な特権だけをユーザーに与えることを意味します。通常のユーザーには、アプリケーションの実行、実行中のジョブのステータスチェック、ファイルの出力、新しいファイルの作成などに必要なだけの特権が与えられます。通常のユーザー権限を超える権限は、権利プロファイルとしてグループ化されます。スーパーユーザー権限の一部が必要なジョブを行うユーザーは、適切な権利プロファイルを含む役割になります。
RBAC では、スーパーユーザー権限を「権利プロファイル」としてまとめます。これらの権利プロファイルは、「役割」と呼ばれる特殊なユーザーアカウントに割り当てられます。ユーザーは、スーパーユーザー権限の一部を必要とするジョブを行う場合に役割になることができます。Oracle Solaris ソフトウェアには、あらかじめ定義された権利プロファイルが用意されています。管理者は役割を作成し、プロファイルを割り当てます。
権利プロファイルを使用することで、さまざまな権限を提供できます。たとえば、Primary Administrator 権利プロファイルはスーパーユーザーと同等です。権限を限定して権利プロファイルを定義することもできます。たとえば、Cron Management 権利プロファイルは at ジョブと cron ジョブを管理します。役割を作成する場合は、多くの権限を持つ役割を作ることも、わずかな権限を持つ役割を作ることもできます。あるいはこの両方を作成することも可能です。
RBAC モデルでは、スーパーユーザーが 1 つ以上の役割を作成します。役割は、権利プロファイルに基づいて作成されます。続いてスーパーユーザーは、役割のタスクに適したユーザーにその役割を割り当てます。ユーザーは、各自のユーザー名でログインします。ログイン後ユーザーは、限定された管理コマンドとグラフィカルユーザーインタフェース (GUI) ツールを実行できる役割を引き受けます。
役割は柔軟に設定できるため、さまざまなセキュリティーポリシーに対応できます。Oracle Solaris には役割がほとんど用意されていませんが、推奨される 4 つの役割を簡単に構成できます。これらの役割は、同じ名前の権利プロファイルに基づいています。次にこれらの役割を示します。
root – root ユーザーと同等の強力な役割。ただし、この root はログインを行うことはできません。通常のユーザーは、ログインしてから、割り当てられた root 役割を引き受ける必要があります。
System Administrator – セキュリティーに関係のない管理作業を行う役割で、権限が限定されています。この役割ではファイルシステム、メール、ソフトウェアのインストールなどを管理できます。ただし、パスワードの設定は行えません。
これらの 3 つの役割の実装は必須ではありません。役割は、組織のセキュリティー要件に応じて設定する機能です。役割は、セキュリティー、ネットワーク、ファイアウォールの管理など、特定の目的の管理に合わせて設定できます。別の方法として、強力な管理者役割を 1 つと上級ユーザー役割を作成することもできます。この上級ユーザー役割は、自分のシステムの各部を修正することを認められたユーザーに割り当てます。
スーパーユーザーモデルと RBAC モデルは共存できます。次の表は、RBAC モデルで設定できる権限 (スーパーユーザーから制限された通常ユーザーまで) を順に挙げ、両モデルで監視できる管理アクションを示しています。システム上での特権の効果だけをまとめた情報としては、表 8-2 を参照してください。
表 8-1 スーパーユーザーモデルと特権を使用した RBAC モデルの比較
|
Oracle Solaris の 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 要素の動作を示します。
図 8-1 Oracle Solaris RBAC 要素の関係
RBAC では、ユーザーに役割が割り当てられます。役割を引き受けると、ユーザーはその役割の権限を利用できる状態となります。役割の権限は権利プロファイルから取得されます。権利プロファイルには、承認、直接割り当てられた特権、特権付きコマンド、その他の補足的な権利プロファイルを含めることができます。特権付きコマンドは、セキュリティー属性を使用して実行されるコマンドです。
次の図は、Network Security 役割と Network Security 権利プロファイルを使用して、RBAC 関係を示したものです。
図 8-2 Oracle Solaris RBAC 要素の関係の例
Network Security 役割は、IPsec、wifi、およびネットワークリンクを管理するために使用されます。この役割は、ユーザー jdoe に割り当てられています。jdoe は、この役割に切り替えて役割のパスワードを入力することにより、この役割を引き受けることができます。
Network Security 権利プロファイルは Network Security 役割に割り当てられています。 Network Security 権利プロファイルには、Network Wifi Security、Network Link Security、および Network IPsec Management という、順番に評価される補助プロファイルが含まれています。これらの補助プロファイルが役割のプライマリタスクに追加されます。
Network Security 権利プロファイルには、直接割り当てられた 3 つの承認と、セキュリティー属性を持つ 2 つのコマンドがありますが、直接割り当てられた特権はありません。補助権利プロファイルには、直接割り当てられた承認があり、それらの 2 つにはセキュリティー属性を持つコマンドがあります。Network Security 役割では、jdoe はこれらのプロファイル内で割り当てられたすべての承認を持ち、これらのプロファイル内のセキュリティー属性を持つすべてのコマンドを実行できます。jdoe はネットワークセキュリティーを管理できます
Oracle Solaris では、管理者がセキュリティーを構成するとき、高い柔軟性が提供されます。 ソフトウェアがインストールされた状態では、特権エスカレーションは許可されません。 特権エスカレーションは、意図していたよりも多くの管理権限がユーザーまたはプロセスに与えられたときに発生します。このため、特権は単なる特権ではなく、あらゆるセキュリティー属性を意味します。
Oracle Solaris ソフトウェアには、root ユーザーにのみ割り当てられるセキュリティー属性が含まれています。他のセキュリティー保護が存在する状態で、管理者は root ユーザー用に設計された属性を別のアカウントに割り当てることができますが、そのような割り当ては注意して行う必要があります。
たとえば、Media Restore という権利プロファイルが存在しますが、これは他の権利プロファイルの一部ではありません。 Media Restore はルートファイルシステム全体へのアクセスを提供するため、これを使用することで特権のエスカレーションが可能です。故意に改ざんされたファイルや交換したメディアを復元できます。デフォルトでは、この権利プロファイルを持つのは root ユーザーのみです。
特権セキュリティー属性に影響するエスカレーションについては、「特権エスカレーションの防止」を参照してください。
「承認」は、役割またはユーザーに許可できる個別の権限です。承認は、ユーザーアプリケーションレベルでポリシーを適用します。
承認は役割またはユーザーに直接割り当てることができますが、承認を権利プロファイルに入れておくことが最善の方法です。権利プロファイルは役割に追加され、役割がユーザーに割り当てられます。例については、図 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 など)
コマンドに特権を指定して権利プロファイルに追加する方法は、「権利プロファイルを作成または変更する方法」を参照してください。特定のプロファイルに特権が存在するか確認するコマンドを調べるには、「割り当てられた特権の判断」を参照してください。
Oracle Solaris には、承認を確認するコマンドも用意されています。当然ながら、root ユーザーにはあらゆる承認が与えられます。このため、root ユーザーは任意のアプリケーションを実行できます。承認があるかどうかを確認するアプリケーションには次のようなものがあります。
Solaris 管理コンソールのすべてのツール
監査管理用のコマンド (auditconfig、auditreduce など)
プリンタ管理用のコマンド (lpadmin、lpfilter など)
バッチジョブ関連のコマンド (at、atq、batch、crontab など)
デバイス向けのコマンド (allocate、deallocate、list_devices、cdrw など)
承認の確認のためにスクリプトまたはプログラムをテストする場合は、例 9-24 を参照してください。承認が必要なプログラムを作成する場合は、『Oracle Solaris 10 セキュリティー開発者ガイド』の「承認について」を参照してください。
「権利プロファイル」は、役割またはユーザーに割り当てることができるシステムの設定をオーバーライドするオペレーションの集合です。権利プロファイルには、承認、割り当て済みのセキュリティー属性が指定されたコマンド、その他の権利プロファイルを含めることができます。権利プロファイル情報は、prof_attr データベースと exec_attr データベースに分けて保存されます。権利プロファイル名と承認は、prof_attr データベースに置かれます。権利プロファイル名と、割り当て済みのセキュリティー属性が指定されたコマンドは、exec_attr データベースに置かれます。
権利プロファイルの詳細は、次のセクションを参照してください。
「役割」は、特権付きアプリケーションを実行できる特別な種類のユーザーアカウントです。役割は、ユーザーアカウントと同じ方法で作成され、ホームディレクトリ、グループ割り当て、パスワードなどを持ちます。権利プロファイルと承認は、役割に管理権限を与えます。役割は、ほかの役割やユーザーから権限を継承することはできません。個々の役割によってスーパーユーザー権限が分配されるため、安全な管理が行えるようになります。
ユーザーが役割を引き受けると、その役割の属性がすべてのユーザー属性を置き換えます。役割情報は、passwd、shadow、および user_attr データベースに保存されます。役割情報の追加は、audit_user データベースに対して行うことができます。役割の設定についての詳細は、次のセクションを参照してください。
各役割は、複数のユーザーに割り当てることができます。同じ役割になるすべてのユーザーは、同じ役割のホームディレクトリを持ち、同じ環境で動作し、同じファイルへのアクセス権を持ちます。ユーザーは、コマンド行から su コマンドを実行し、役割名とパスワードを指定して役割を引き受けることができます。Solaris 管理コンソールツールで役割を引き受けることもできます。
役割自体が直接ログインすることはできません。ユーザーがまずログインし、続いて役割を引き受けます。役割を引き受けたあとは、その役割を終了するまでほかの役割を引き受けることはできません。つまり、その役割を終了すれば、ほかの役割を引き受けることができます。
「root ユーザーを役割にする方法」に示しているように、root ユーザーを役割に変更することによって、匿名の root ログインを防ぐことができます。プロファイルシェルコマンド pfexec が監査の対象となっている場合、監査トレールにはログインユーザーの実 UID、そのユーザーが引き受けた役割、およびその役割が行なったアクションが記録されます。役割による処理を行うシステムまたは特定のユーザーを監査する方法については、「役割を監査する方法」を参照してください。
Oracle Solaris には、事前に定義された役割は用意されていません。ただし、ソフトウェアに付属している権利プロファイルは、役割に対応付けられています。たとえば、Primary Administrator 権利プロファイルを使用すると、Primary Administrator 役割を作成できます。
プライマリ管理者役割を構成するには、『Oracle Solaris の管理: 基本管理』の「Solaris 管理ツールを RBAC と組み合わせて使用する (タスクマップ)」を参照してください。
ほかの役割を構成するには、「GUI を使用して役割の作成および割り当てを行う方法」を参照してください。
コマンド行で役割を作成する方法については、「RBAC の管理(タスクマップ)」を参照してください。
役割は、特権付きアプリケーションを Solaris 管理コンソール起動ツールから実行することも、あるいは「プロファイルシェル」から実行することもできます。プロファイルシェルプロファイルシェルは、権利プロファイルに含まれるセキュリティー属性を認識する特殊なシェルです。プロファイルシェルは、ユーザーが su コマンドを実行して役割を引き受けたときに起動されます。プロファイルシェルには、pfsh、pfcsh、および pfksh があります。これらはそれぞれ、Bourne シェル (sh)、C シェル (csh)、および Korn シェル (ksh) に対応します。
権利プロファイルが直接割り当てられたユーザーは、セキュリティー属性が指定されたコマンドを実行する場合、プロファイルシェルを起動する必要があります。操作性やセキュリティーに関する考慮事項については、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。
プロファイルシェルで実行されるコマンドはすべて、監査の対象に含めることができます。詳細は、「役割を監査する方法」を参照してください。
ネームサービススコープは、RBAC を理解する上で重要な概念です。役割の適用範囲は、個々のホストに限定されることがあります。ネームサービス (NIS、NIS+、または LDAP) のサービス対象となるすべてのホストとなることもあります。システムにおけるネームサービススコープは、/etc/nsswitch.conf で指定します。検索は、最初に一致した時点で停止します。たとえば、権利プロファイルが 2 つのネームサービススコープに存在する場合、最初のネームサービススコープに含まれるエントリだけが使用されます。最初に一致したものが files の場合、役割の適用範囲はローカルホストに限定されます。
一般にユーザーは、役割を通して管理権限を取得します。承認と、特権付きコマンドは、権利プロファイル内でグループ化されます。権利プロファイルは役割に含められ、役割がユーザーに割り当てられます。
権利プロファイルとセキュリティー属性を直接割り当てることも可能です。
ユーザーには、権利プロファイル、特権、および承認を直接割り当てることができます。
役割とユーザーには、特権と承認を直接割り当てることができます。
しかし、特権の割り当てを直接行うことは安全とは言えません。特権が直接割り当てられたユーザーと役割は、カーネルがその特権を要求するどの場合でもセキュリティーポリシーをオーバーライドできます。安全なやり方は、特権をコマンドのセキュリティー属性として権利プロファイル内で割り当てる方法です。そうすると、その特権は、その権利プロファイルを持つユーザーが、そのコマンドでのみ使用できます。
承認はユーザーレベルで作用するため、承認の直接割り当ては特権の直接割り当てよりリスクが小さいと言えます。しかし、承認が与えられることで、ユーザーは監査フラグの割り当てなどの高いセキュリティーが求められるタスクも実施できるようになります。
ユーザーに直接割り当てられた権利プロファイルでは、セキュリティーよりも操作性に関して問題が多く発生します。権利プロファイルでセキュリティー属性が指定されたコマンドは、プロファイルシェルでしか実行できません。ユーザーはプロファイルシェルを開き、そのシェルにコマンドを入力する必要があります。権利プロファイルが割り当てられた役割は、プロファイルシェルを自動的に取得します。このため、コマンドはその役割のシェルで正常に実行されます。