JavaScript is required to for searching.
ナビゲーションリンクをスキップ
印刷ビューの終了
Solaris のシステム管理 (セキュリティサービス)     Oracle Solaris 10 8/11 Information Library (日本語)
search filter icon
search icon

ドキュメントの情報

はじめに

パート I セキュリティーの概要

1.  セキュリティーサービス (概要)

パート II システム、ファイル、およびデバイスのセキュリティー

2.  マシンセキュリティーの管理 (概要)

3.  システムアクセスの制御 (作業)

4.  デバイスアクセスの制御 (作業)

5.  基本監査報告機能の使用方法 (作業)

6.  ファイルアクセスの制御 (作業)

7.  自動セキュリティー拡張ツールの使用 (手順)

パート III 役割、権利プロファイル、特権

8.  役割と特権の使用 (概要)

RBAC の新機能

役割によるアクセス制御 (概要)

RBAC: スーパーユーザーモデルの代替機能

Oracle Solaris RBAC の要素と基本概念

特権エスカレーション

RBAC の承認

承認と特権

特権付きアプリケーションと RBAC

UID と GID を確認するアプリケーション

特権を確認するアプリケーション

承認を確認するアプリケーション

RBAC の権利プロファイル

RBAC の役割

プロファイルシェルと RBAC

ネームサービススコープと RBAC

セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項

特権 (概要)

カーネルプロセスを保護する特権

特権の種類

特権を使用したシステムにおける管理上の相違点

特権とシステム資源

特権の実装方法

プロセスが特権を取得する方法

特権の割り当て

ユーザーまたは役割の特権の拡張

ユーザーまたは役割の特権の制限

スクリプトへの特権の割り当て

特権とデバイス

特権とデバッグ

9.  役割によるアクセス制御の使用 (手順)

10.  役割によるアクセス制御 (参照)

11.  特権 (手順)

12.  特権 (参照)

パート IV 暗号化サービス

13.  Oracle Solaris の暗号化フレームワーク (概要)

14.  Oracle Solaris の暗号化フレームワーク (手順)

15.  Oracle Solaris 鍵管理フレームワーク

パート V 認証サービスと安全な通信

16.  認証サービスの使用 (手順)

17.  PAM の使用

18.  SASL の使用

19.  Oracle Solaris Secure Shell の使用 (手順)

20.  Oracle Solaris Secure Shell (参照)

パート VI Kerberos サービス

21.  Kerberos サービスについて

22.  Kerberos サービスの計画

23.  Kerberos サービスの構成 (手順)

24.  Kerberos エラーメッセージと障害追跡

25.  Kerberos 主体とポリシーの管理 (手順)

26.  Kerberos アプリケーションの使用 (手順)

27.  Kerberos サービス (参照)

パート VII Oracle Solaris 監査

28.  Oracle Solaris 監査 (概要)

29.  Oracle Solaris 監査の計画

30.  Oracle Solaris 監査の管理 (手順)

31.  Oracle Solaris 監査 (参照)

用語集

索引

役割によるアクセス制御 (概要)

役割によるアクセス制御 (RBAC) は、通常はスーパーユーザーに限定されているタスクに対するユーザーアクセスを制御するセキュリティー機能です。RBAC では、プロセスやユーザーにセキュリティー属性を適用することで、スーパーユーザーの権限を複数の管理者に分けることができます。プロセス権管理は、「特権」を介して実装されます。ユーザー権管理は RBAC によって行われます。

RBAC: スーパーユーザーモデルの代替機能

従来の UNIX システムでは、root ユーザー (スーパーユーザーとも呼ばれる) が全権を有します。root として実行されるプログラム、または setuid プログラムにも全権があります。root ユーザーは全ファイルの読み取り権とアクセス権、全プログラムの実行権を持ち、任意のプロセスに終了シグナルを送ることができます。実際、スーパーユーザーになるユーザーは、使用するサイトのファイアウォールの変更、監査トレールの変更、機密レコードの読み取り、ネットワーク全体の停止などを行えます。setuid プログラムがハイジャック (強奪) されると、システム上で何が起きても不思議はありません。

役割によるアクセス制御 (RBAC) は、絶対的なスーパーユーザーモデルに代わるより厳密な機密保護機能です。RBAC を使用することで、セキュリティーポリシーをきめ細かく適用できます。RBAC では、「最小特権」というセキュリティー原則が使用されます。最小特権は、ジョブを行う上で必要な特権だけをユーザーに与えることを意味します。通常のユーザーには、アプリケーションの実行、実行中のジョブの状態チェック、ファイルの出力、新しいファイルの作成などに必要なだけの特権が与えられます。通常のユーザー権限を超える権限は、権利プロファイルとしてグループ化されます。スーパーユーザー権限の一部が必要なジョブを行うユーザーは、適切な権利プロファイルを含む役割を引き受けます。

RBAC では、スーパーユーザー権限を「権利プロファイル」としてまとめます。これらの権利プロファイルは、「役割」と呼ばれる特殊なユーザーアカウントに割り当てられます。ユーザーは、スーパーユーザー権限の一部を必要とするジョブを行う場合に役割を引き受けることができます。Oracle Solaris ソフトウェアには、あらかじめ定義された権利プロファイルが用意されています。管理者は役割を作成し、プロファイルを割り当てます。

権利プロファイルを使用することで、さまざまな権限を提供できます。たとえば、Primary Administrator 権利プロファイルはスーパーユーザーと同等です。権限を限定して権利プロファイルを定義することもできます。たとえば、Cron Management 権利プロファイルは at ジョブと cron ジョブを管理します。役割を作成する場合は、多くの権限を持つ役割を作ることも、わずかな権限を持つ役割を作ることもできます。あるいはこの両方を作成することも可能です。

RBAC モデルでは、スーパーユーザーが 1 つ以上の役割を作成します。役割は、権利プロファイルに基づいて作成されます。続いてスーパーユーザーは、役割の作業に適したユーザーにその役割を割り当てます。ユーザーは、各自のユーザー名でログインします。ログイン後ユーザーは、限定された管理コマンドとグラフィカルユーザーインタフェース (GUI) ツールを実行できる役割を引き受けます。

役割は柔軟に設定できるため、さまざまなセキュリティーポリシーに対応できます。Oracle Solaris には標準装備された役割がほとんどありませんが、推奨される 3 つの役割を簡単に構成できます。これらの役割は、同じ名前の権利プロファイルに基づいています。次にこれらの役割を示します。

これらの 3 つの役割の実装は必須ではありません。役割は、組織のセキュリティー要件に応じて設定する機能です。役割は、セキュリティー、ネットワーク、ファイアウォールの管理など、特定の目的の管理に合わせて設定できます。別の方法として、強力な管理者役割を 1 つと上級ユーザー役割を作成することもできます。この上級ユーザー役割は、自分のシステムの各部を修正することを認められたユーザーに割り当てます。

スーパーユーザーモデルと RBAC モデルは共存できます。次の表は、RBAC モデルで設定できる権限 (スーパーユーザーから制限された通常ユーザーまで) を順に挙げ、両モデルで監視できる管理アクションを示しています。システム上での特権の効果だけをまとめた情報としては、表 8-2 を参照してください。

表 8-1 スーパーユーザーモデルと特権を使用した RBAC モデルの比較

システムにおけるユーザー権限
スーパーユーザーモデル
RBAC モデル
すべてのスーパーユーザー権限を持つスーパーユーザーになる
はい
はい
すべてのユーザー権限を持つユーザーとしてログインする
はい
はい
権限が限定されたスーパーユーザーになる
いいえ
はい
ユーザーとしてログインし、散発的にスーパーユーザー権限を持つ
可能 (setuid プログラムのみ)
可能 (setuid プログラム、および RBAC を使用)
すべてのスーパーユーザー権限ではなく、一部の管理権限だけを持つユーザーとしてログインする
いいえ
可能 (RBAC を使用、および直接割り当てられた特権と承認を使用)
通常のユーザーよりも少ない権限を持つユーザーとしてログインする
いいえ
可能 (RBAC を使用、および特権を削除してログイン)
スーパーユーザーの処理を監視する
可能 (su コマンドを監査することによって監視)
可能 (プロファイルシェルコマンドを監査することによって監視)

root ユーザーが無効になっている場合には、root 役割を引き受けたユーザーの名前が監査トレールに入ります

Oracle Solaris RBAC の要素と基本概念

Oracle Solaris の RBAC モデルでは、次の要素が導入されました。

次の図では、各 RBAC 要素の動作を示します。

図 8-1 Oracle Solaris RBAC 要素の関係

image:この図については次に説明します。

RBAC では、ユーザーに役割が割り当てられます。役割を引き受けると、ユーザーはその役割の権限を利用できる状態となります。役割の権限は権利プロファイルから取得されます。権利プロファイルには、承認、直接割り当てられた特権、特権付きコマンド、その他の補足的な権利プロファイルを含めることができます。特権付きコマンドは、セキュリティー属性を使用して実行されるコマンドです。

次の図は、Network Security 役割と Network Security 権利プロファイルを使用して、RBAC 関係を示したものです。

図 8-2 Oracle Solaris RBAC 要素の関係の例

image:この図については次に説明します。

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 ユーザーのみです。

特権セキュリティー属性に影響するエスカレーションについては、「特権エスカレーションの防止」を参照してください。

RBAC の承認

「承認」は、役割またはユーザーに許可できる個別の権限です。承認は、ユーザーアプリケーションレベルでポリシーを適用します。

承認は役割またはユーザーに直接割り当てることができますが、承認を権利プロファイルに入れておくことが最善の方法です。権利プロファイルは役割に追加され、役割がユーザーに割り当てられます。例については、図 8-2 を参照してください。

RBAC に準拠したアプリケーションは、ユーザーの承認を確認してから、アプリケーションまたはアプリケーション内の特定の操作に対するアクセス権を許可します。この承認の確認は、従来の UNIX アプリケーションが行なっていた UID=0 の確認に代わるものです。承認についての詳細は次の節で説明します。

承認と特権

特権は、カーネル内でセキュリティーポリシーを適用します。承認と特権の違いは、セキュリティーポリシーが適用されるレベルにあります。プロセスに適切な特権がないと、特権化された処理の実行がカーネルによって防止される可能性があります。適切な承認が与えられていないユーザーは、特権付きアプリケーションを使用できなかったり、特権付きアプリケーションに含まれるセキュリティーの厳しい処理を実行できなかったりする可能性があります。特権についての詳細は、「特権 (概要)」を参照してください。

特権付きアプリケーションと RBAC

システム制御に優先するアプリケーションとコマンドは、特権付きアプリケーションとみなされます。アプリケーションは、UID=0 のようなセキュリティー属性、特権、および承認によって特権化されます。

UID と GID を確認するアプリケーション

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 権利プロファイルメカニズムを使用すれば、特定のコマンドに特権を指定できます。この方法では、アプリケーションまたはコマンドの実行時にスーパーユーザー権限を要求するのではなく、実行セキュリティー属性を指定してコマンドを権利プロファイルとして分離します。この権利プロファイルを持つユーザーまたは役割は、そのコマンドの実行に必要な特権だけを使用してコマンドを実行できます。

特権を確認するコマンドとして次のようなものがあります。

コマンドに特権を指定して権利プロファイルに追加する方法は、「権利プロファイルを作成または変更する方法」を参照してください。特定のプロファイルに特権が存在するか確認するコマンドを調べる場合は、「割り当てられた特権の判断」を参照してください。

承認を確認するアプリケーション

Oracle Solaris には、承認を確認するコマンドも用意されています。当然ながら、root ユーザーにはあらゆる承認が与えられます。このため、root ユーザーは任意のアプリケーションを実行できます。承認があるかどうかを確認するアプリケーションには次のようなものがあります。

承認の確認のためにスクリプトまたはプログラムをテストする場合は、例 9-24 を参照してください。承認が必要なプログラムを作成する場合は、『Oracle Solaris セキュリティーサービス開発ガイド』の「承認について」を参照してください。

RBAC の権利プロファイル

「権利プロファイル」は、役割またはユーザーに割り当てることができるシステムの設定より優先されるオペレーションの集合です。権利プロファイルには、承認、割り当て済みのセキュリティー属性が指定されたコマンド、その他の権利プロファイルを含めることができます。権利プロファイル情報は、prof_attr データベースと exec_attr データベースに分けて保存されます。権利プロファイル名と承認は、prof_attr データベースに置かれます。権利プロファイル名と、割り当て済みのセキュリティー属性が指定されたコマンドは、exec_attr データベースに置かれます。

権利プロファイルの詳細は、次の節を参照してください。

RBAC の役割

「役割」は、特権付きアプリケーションを実行できる特別な種類のユーザーアカウントです。役割は、ユーザーアカウントと同じ方法で作成され、ホームディレクトリ、グループ割り当て、パスワードなどを持ちます。権利プロファイルと承認は、役割に管理権限を与えます。役割は、ほかの役割やユーザーから権限を継承することはできません。個々の役割によってスーパーユーザー権限が分配されるため、安全な管理が行えるようになります。

ユーザーが役割を引き受けると、その役割の属性がすべてのユーザー属性を置き換えます。役割情報は、passwdshadow、 および user_attr データベースに保存されます。役割情報の追加は、audit_user データベースに対して行うことができます。役割の設定についての詳細は、次の節を参照してください。

各役割は、複数のユーザーに割り当てることができます。同じ役割になるすべてのユーザーは、同じ役割のホームディレクトリを持ち、同じ環境で動作し、同じファイルへのアクセス権を持ちます。ユーザーは、コマンド行から su コマンドを実行し、役割名とパスワードを指定して役割を引き受けることができます。Solaris 管理コンソールツールで役割を引き受けることもできます。

役割自体が直接ログインすることはできません。ユーザーがまずログインし、続いて役割を引き受けます。役割を引き受けたあとは、その役割を終了するまでほかの役割を引き受けることはできません。つまり、その役割を終了すれば、ほかの役割を引き受けることができます。

root ユーザーを役割にする方法」に示しているように、root ユーザーを役割に変更することによって、匿名の root ログインを防ぐことができます。プロファイルシェルコマンド pfexec が監査の対象となっている場合、監査トレールにはログインユーザーの実 UID、 そのユーザーが引き受けた役割、およびその役割が行ったアクションが記録されます。役割による処理を行うシステムまたは特定のユーザーを監査する方法については、「役割を監査する方法」を参照してください。

Oracle Solaris には、事前に定義された役割は用意されていません。ただし、ソフトウェアに付属している権利プロファイルは、役割に対応付けられています。たとえば、Primary Administrator 権利プロファイルを使用すると、Primary Administrator 役割を作成できます。

プロファイルシェルと RBAC

役割は、特権付きアプリケーションを Solaris 管理コンソール起動ツールから実行することも、あるいは「プロファイルシェル」から実行することもできます。プロファイルシェルプロファイルシェルは、権利プロファイルに含まれるセキュリティー属性を認識する特殊なシェルです。プロファイルシェルは、ユーザーが su コマンドを実行して役割を引き受けたときに起動されます。プロファイルシェルには、pfshpfcsh、 および pfksh があります。これらはそれぞれ、Bourne シェル (sh)、 C シェル (csh)、 および Korn シェル (ksh) に対応します。

権利プロファイルが直接割り当てられたユーザーは、セキュリティー属性が指定されたコマンドを実行する場合、プロファイルシェルを起動する必要があります。操作性やセキュリティーに関する考慮事項については、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。

プロファイルシェルで実行されるコマンドはすべて、監査の対象に含めることができます。詳細は、「役割を監査する方法」を参照してください。

ネームサービススコープと RBAC

ネームサービススコープは、RBAC を理解する上で重要な概念です。役割の適用範囲は、個々のホストに限定されることもあれば、ネームサービス (NIS、 NIS+、 または LDAP) のサービス対象となるすべてのホストとなることもあります。システムにおけるネームサービススコープは、/etc/nsswitch.conf で指定します。検索は、最初に一致した時点で停止します。たとえば、権利プロファイルが 2 つのネームサービススコープに存在する場合、最初のネームサービススコープに含まれるエントリだけが使用されます。最初に一致したものが files の場合、役割の適用範囲はローカルホストに限定されます。

セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項

一般にユーザーは、役割を通して管理権限を取得します。承認と、特権付きコマンドは、権利プロファイル内でグループ化されます。権利プロファイルは役割に含められ、役割がユーザーに割り当てられます。

権利プロファイルとセキュリティー属性を直接割り当てることも可能です。

しかし、特権の割り当てを直接行うことは安全とは言えません。特権が直接割り当てられたユーザーと役割は、カーネルがその特権を要求するどの場合でもセキュリティーポリシーに優先します。安全なやり方は、特権をコマンドのセキュリティー属性として権利プロファイル内で割り当てる方法です。そうすると、その特権は、その権利プロファイルを持つユーザーが、そのコマンドでのみ使用できます。

承認はユーザーレベルで作用するため、承認の直接割り当ては特権の直接割り当てよりリスクが小さいと言えます。しかし、承認が与えられることで、ユーザーは監査フラグの割り当てなどの高いセキュリティーが求められる作業も実施できるようになります。

ユーザーに直接割り当てられた権利プロファイルでは、セキュリティーよりも操作性に関して問題が多く発生します。権利プロファイルでセキュリティー属性が指定されたコマンドは、プロファイルシェルでしか実行できません。ユーザーはプロファイルシェルを開き、そのシェルにコマンドを入力する必要があります。権利プロファイルが割り当てられた役割は、プロファイルシェルを自動的に取得します。このため、コマンドはその役割のシェルで正常に実行されます。