| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris の管理: セキュリティーサービス Oracle Solaris 11 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris の管理: セキュリティーサービス Oracle Solaris 11 Information Library (日本語) |
パート II システム、ファイル、およびデバイスのセキュリティー
10. Oracle Solaris のセキュリティー属性 (参照)
22. Kerberos エラーメッセージとトラブルシューティング
役割に基づくアクセス制御 (RBAC) は、通常は root 役割に限定されているタスクへのユーザーアクセスを制御するためのセキュリティー機能です。RBAC では、プロセスやユーザーにセキュリティー属性を適用することで、スーパーユーザーの権限を複数の管理者に分けることができます。プロセス権管理は、「特権」を介して実装されます。ユーザー権管理は RBAC によって行われます。
プロセス権管理については、「特権 (概要)」を参照してください。
RBAC のタスクについては、第 9 章役割に基づくアクセス制御の使用 (タスク)を参照してください。
参照情報については、第 10 章Oracle Solaris のセキュリティー属性 (参照)を参照してください。
従来の UNIX システムでは、root ユーザー (スーパーユーザーとも呼ばれる) が全権を有します。root として実行されるプログラム、または setuid プログラムにも全権があります。root ユーザーは全ファイルの読み取り権とアクセス権、全プログラムの実行権を持ち、任意のプロセスに終了シグナルを送ることができます。実際、スーパーユーザーになるユーザーは、使用するサイトのファイアウォールの変更、監査トレールの変更、機密レコードの読み取り、ネットワーク全体の停止などを行えます。setuid プログラムがハイジャック (強奪) されると、システム上で何が起きても不思議はありません。
役割に基づくアクセス制御 (RBAC) は、絶対的なスーパーユーザーモデルに代わるより厳密な機密保護機能です。RBAC を使用することで、セキュリティーポリシーをきめ細かく適用できます。RBAC では、「最小特権」というセキュリティー原則が使用されます。最小特権は、ジョブを行う上で必要な特権だけをユーザーに与えることを意味します。通常のユーザーには、アプリケーションの使用、実行中のジョブのステータスチェック、ファイルの印刷、新しいファイルの作成などを行うための十分な特権が与えられます。通常のユーザー権限を越える権限は、権利プロファイルにグループ化されます。スーパーユーザー権限の一部が必要なジョブを行うユーザーは、適切な権利プロファイルを含む役割になります。
RBAC では、スーパーユーザー権限を「権利プロファイル」としてまとめます。これらの権利プロファイルは、「役割」と呼ばれる特殊なユーザーアカウントに割り当てられます。ユーザーは、スーパーユーザー権限の一部を必要とするジョブを行う場合に役割になることができます。Oracle Solaris ソフトウェアには、あらかじめ定義された権利プロファイルが用意されています。管理者は役割を作成し、プロファイルを割り当てます。
権利プロファイルを使用することで、さまざまな権限を提供できます。たとえば、System Administrator 権利プロファイルを使用すると、アカウントはプリンタ管理や cron ジョブなどのセキュリティーに関連しないタスクを実行できます。権限を限定して権利プロファイルを定義することもできます。たとえば、Cron Management 権利プロファイルは at ジョブと cron ジョブを管理します。役割を作成するときは、その役割に広い権限または狭い権限、あるいはその両方を割り当てることができます。
次の図は、RBAC により、信頼できる相手に権限をどのように分散できるかを示しています。
図 8-1 RBAC による権限の分散
RBAC モデルでは、スーパーユーザーが 1 つ以上の役割を作成します。役割は、権利プロファイルに基づいて作成されます。続いてスーパーユーザーは、役割のタスクに適したユーザーにその役割を割り当てます。ユーザーは、各自のユーザー名でログインします。ログイン後ユーザーは、限定された管理コマンドとグラフィカルユーザーインタフェース (GUI) ツールを実行できる役割を引き受けます。
役割は柔軟に設定できるため、さまざまなセキュリティーポリシーに対応できます。Oracle Solaris には標準装備された役割がほとんどありませんが、さまざまな役割を容易に構成できます。ほとんどの役割は、同じ名前の権利プロファイルに基づいて構成できます。
root – root ユーザーと同等の強力な役割。ただし、この root はログインを行うことはできません。通常のユーザーは、ログインしてから、割り当てられた root 役割を引き受ける必要があります。この役割は、デフォルトで構成されています。
System Administrator – セキュリティーに関係のない管理作業を行う役割で、権限が限定されています。この役割ではファイルシステム、メール、ソフトウェアのインストールなどを管理できます。ただし、パスワードの設定は行えません。
1 つ以上のセキュリティー役割を構成することもできます。セキュリティーは、Information Security、User Security、および Zone Security の 3 つの権利プロファイルと、それらの補助プロファイルによって処理されます。ネットワークセキュリティーは、Information Security 権利プロファイル内の補助プロファイルです。
これらの役割を実装する必要はありません。役割は、組織のセキュリティー要件に応じて設定する機能です。1 つの方法として、セキュリティー、ネットワーク、ファイアウォール管理などの領域における専用の管理者のための役割を設定します。別の方法として、強力な管理者役割を 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 モデルでは、setuid および setgid プログラムに加えて、承認と特権がセキュリティー属性になります。これらの属性をユーザーに割り当てることができます。たとえば、solaris.device.allocate 承認が与えられたユーザーは、デバイスを独占的に使用するためにそのデバイスの割り当てを行うことができます。特権をプロセスに割り当てることができます。たとえば、file_flag_set 特権を持つプロセスは、変更不可能な、リンク解除できない、または追加のみのファイル属性を設定できます。
特権付きアプリケーション – セキュリティー属性を確認することによってシステム制御に優先するアプリケーションまたはコマンド。典型的な UNIX 環境と RBAC モデルでは、setuid と setgid を使用するプログラムは特権付きアプリケーションです。RBAC モデルでは、処理を正常に実行する上で特権または承認を必要とするプログラムも特権付きアプリケーションです。詳細は、「特権付きアプリケーションと RBAC」を参照してください。
権利プロファイル – 役割またはユーザーに割り当てることができるセキュリティー属性の集合。権利プロファイルには、承認、直接割り当てられた特権、セキュリティー属性を持つコマンド、およびほかの権利プロファイルを含めることができます。別のプロファイル内に存在するプロファイルは、補助権利プロファイルと呼ばれます。権利プロファイルは、セキュリティー属性をグループ化する手段として便利です。
役割 – 特権付きアプリケーションを実行するための特殊な識別情報。この特殊な識別情報を取得できるのは、あらかじめ割り当てられたユーザーだけです。役割 (root 役割を含む) によって実行されるシステムでは、スーパーユーザーは必要ありません。スーパーユーザー権限はいくつかの役割に分散されます。たとえば、役割が 2 つ存在するシステムでは、セキュリティータスクをセキュリティー役割によって処理し、セキュリティー関連ではないシステム管理タスクを他方の役割で処理できます。役割を細かく分割することも可能です。たとえば、システムに、暗号化フレームワーク、プリンタ、システム時刻、ファイルシステム、および監査を処理するための個別の管理役割を含めることができます。
次の図では、各 RBAC 要素の動作を示します。
図 8-2 RBAC 要素の関係
次の図は、Network Security 役割と Network Security 権利プロファイルを使用して、RBAC 関係を示したものです。
図 8-3 RBAC 要素の関係の例
Network Security 役割は、IPsec、wifi、およびネットワークリンクを管理するために使用されます。この役割は、ユーザー jdoe に割り当てられています。jdoe は、この役割に切り替えて役割のパスワードを入力することにより、この役割を引き受けることができます。管理者は、役割のパスワードではなくユーザーパスワードを受け入れるようにこの役割をカスタマイズできます。
図 8-3 では、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 役割用に設計された属性を管理者がほかのアカウントに割り当てる可能性がありますが、このような割り当ては慎重に行う必要があります。
次の権利プロファイルと一連の承認は、root 以外のアカウントの特権をエスカレートできます。
Media Restore 権利プロファイル – このプロファイルは存在しますが、ほかのどの権利プロファイルにも含まれていません。Media Restore はルートファイルシステム全体へのアクセスを提供するため、これを使用することで特権のエスカレーションが可能です。故意に改ざんされたファイルや交換したメディアを復元できます。デフォルトでは、root 役割にはこの権利プロファイルが含まれています。
solaris.*.assign 承認 – これらの承認は存在しますが、どの権利プロファイルまたはアカウントにも割り当てられていません。solaris.*.assign 承認を持つアカウントは、そのアカウント自体に割り当てられていないセキュリティー属性をほかのユーザーに割り当てることができます。たとえば、solaris.profile.assign 承認を持つ役割は、その役割自体に割り当てられていない権利プロファイルをほかのアカウントに割り当てることができます。デフォルトでは、solaris.*.assign 承認を持つのは root 役割だけです。
ベストプラクティスは、solaris.*.assign 承認ではなく、solaris.*.delegate 承認を割り当てることです。solaris.*.delegate 承認を使用すると、委託者は、その委託者が所有するセキュリティー属性のみをほかのアカウントに割り当てることができます。たとえば、solaris.profile.delegate 承認が割り当てられた役割は、その役割自体に割り当てられている権利プロファイルをほかのユーザーや役割に割り当てることができます。
特権セキュリティー属性に影響するエスカレーションについては、「特権エスカレーションの防止」を参照してください。
「承認」は、役割またはユーザーに許可できる個別の権限です。承認は、ユーザーアプリケーションレベルでポリシーを適用します。
承認は役割またはユーザーに直接割り当てることができますが、承認を権利プロファイルに入れておくことが最善の方法です。権利プロファイルは役割に追加され、役割がユーザーに割り当てられます。例については、図 8-3を参照してください。
delegate または assign という単語を含む承認を使用すると、ユーザーまたは役割は、セキュリティー属性をほかのユーザーに割り当てることができます。
特権のエスカレーションを回避するために、アカウントに assign 承認を割り当てないでください。
delegate 承認を使用すると、委託者は、その委託者が所有するセキュリティー属性のみをほかのユーザーに割り当てることができます。たとえば、solaris.profile.delegate 承認が割り当てられた役割は、その役割自体に割り当てられている権利プロファイルをほかのユーザーに割り当てることができます。
assign 承認を使用すると、割り当て者は、そのアカウントが所有していないセキュリティー属性をほかのユーザーに割り当てることができます。たとえば、solaris.profile.assign 承認を持つ役割は、任意の権利プロファイルをほかのユーザーに割り当てることができます。
solaris.*.assign 承認は提供されていますが、どのプロファイルにも含まれていません。デフォルトでは、solaris.*.assign 承認を持つのは root 役割だけです。
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 も設定できます。たとえば、reboot コマンドには実効 UID ではなく、実 UID が必要です。あるコマンドを実行するために実効 ID では十分でない場合は、そのコマンドに実 ID を割り当てる必要があります。
特権付きアプリケーションでは、特権の使用を確認できます。RBAC 権利プロファイルメカニズムを使用すると、セキュリティー属性が必要な特定のコマンドの特権を指定できます。次に、セキュリティー属性が割り当てられたコマンドを権利プロファイル内に分離できます。この権利プロファイルを持つユーザーまたは役割は、そのコマンドの実行に必要な特権だけを使用してコマンドを実行できます。
Kerberos コマンド (kadmin、kprop、kdb5_util など)
ネットワークコマンド (ipadm、routeadm、snoop など)
ファイルコマンドとファイルシステムコマンド (chmod、chgrp、mount など)
プロセスを制御するコマンド (kill、pcred、rcapadm など)
特権を持つコマンドを権利プロファイルに追加するには、「権利プロファイルを作成または変更する方法」および profiles(1) のマニュアルページを参照してください。特定のプロファイル内の特権がどのコマンドで確認されるかを判定するには、「定義済みのすべてのセキュリティー属性を表示する方法」を参照してください。
Oracle Solaris には、承認を確認するコマンドも用意されています。当然ながら、root ユーザーにはあらゆる承認が与えられます。このため、root ユーザーは任意のアプリケーションを実行できます。承認があるかどうかを確認するアプリケーションには次のようなものがあります。
監査管理用のコマンド (auditconfig、auditreduce など)
プリンタ管理用のコマンド (lpadmin、lpfilter など)
バッチジョブ関連のコマンド (at、atq、batch、crontab など)
デバイス向けのコマンド (allocate、deallocate、list_devices、cdrw など)
承認の確認のためにスクリプトまたはプログラムをテストする場合は、例 9-16 を参照してください。承認が必要なプログラムを作成するには、『Oracle Solaris 11 セキュリティーサービス開発ガイド』の「承認について」を参照してください。
権利プロファイルは、管理権限が必要なタスクを実行するために役割またはユーザーに割り当てることができるセキュリティー属性の集合です。権利プロファイルには、承認、特権、セキュリティー属性が割り当てられたコマンド、およびほかの権利プロファイルを含めることができます。権利プロファイル内で割り当てられた特権は、すべてのコマンドで有効です。権利プロファイルにはまた、初期の継承可能セットを削減または拡張したり、特権の制限セットを削減したりするためのエントリも含まれています。
権利プロファイルについての詳細は、次のセクションを参照してください。
「役割」は、特権付きアプリケーションを実行できる特別な種類のユーザーアカウントです。役割は、ユーザーアカウントと同じ方法で作成され、ホームディレクトリ、グループ割り当て、パスワードなどを持ちます。権利プロファイルと承認は、役割に管理権限を与えます。役割は、ほかの役割やユーザーから権限を継承することはできません。個々の役割によってスーパーユーザー権限が分配されるため、安全な管理が行えるようになります。
ユーザーが役割を引き受けると、その役割の属性がすべてのユーザー属性を置き換えます。役割情報は、passwd、shadow、および user_attr データベースに保存されます。役割のアクションを監査できます。役割の設定についての詳細は、次のセクションを参照してください。
各役割は、複数のユーザーに割り当てることができます。同じ役割になるすべてのユーザーは、同じ役割のホームディレクトリを持ち、同じ環境で動作し、同じファイルへのアクセス権を持ちます。ユーザーは、su コマンドを実行し、役割名とパスワードを指定することによって、コマンド行から役割を引き受けることができます。デフォルトでは、ユーザーが役割に対して認証されるには、その役割のパスワードを指定します。管理者は、ユーザーが、そのユーザーのパスワードを指定することによって認証できるようにシステムを構成できます。手順については、「ユーザーが自分のパスワードを使用して役割になれるようにする方法」を参照してください。
役割自体が直接ログインすることはできません。ユーザーがまずログインし、続いて役割を引き受けます。役割を引き受けたあとは、その役割を終了するまでほかの役割を引き受けることはできません。つまり、その役割を終了すれば、ほかの役割を引き受けることができます。
Oracle Solaris では root は役割であるため、匿名の root ログインが回避されます。プロファイルシェルコマンド pfexec が監査の対象となっている場合、監査トレールにはログインユーザーの実 UID、そのユーザーが引き受けた役割、およびその役割が行ったアクションが記録されます。役割による処理を行うシステムまたは特定のユーザーを監査する方法については、「役割を監査する方法」を参照してください。
ソフトウェアに付属する権利プロファイルは、役割に対応するように設計されています。たとえば、System Administrator 権利プロファイルを使用すると、System Administrator 役割を作成できます。役割を構成するには、「役割を作成する方法」を参照してください。
ユーザーや役割は、プロファイルシェルから特権付きアプリケーションを実行できます。プロファイルシェルは、権利プロファイルに含まれるセキュリティー属性を認識する特殊なシェルです。管理者は、プロファイルシェルをログインシェルとして特定のユーザーに割り当てることができます。そうでない場合は、そのユーザーが役割になるために su コマンドを実行したときに、プロファイルシェルが起動されます。Oracle Solaris では、どのシェルにも、対応するプロファイルシェルがあります。たとえば、Bourne シェル (sh)、bash シェル (csh)、および Korn シェル (ksh) に対応するプロファイルシェルは、それぞれ pfsh、pfbash、および pfksh シェルです。プロファイルシェルのリストについては、pfexec(1) のマニュアルページを参照してください。
権利プロファイルが直接割り当てられていて、ログインシェルがプロファイルシェルではないユーザーが、セキュリティー属性が割り当てられたコマンドを実行するには、プロファイルシェルを呼び出す必要があります。操作性やセキュリティーに関する考慮事項については、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。
プロファイルシェルで実行されるコマンドはすべて、監査の対象に含めることができます。詳細は、「役割を監査する方法」を参照してください。
ネームサービススコープは、RBAC を理解する上で重要な概念です。役割の適用範囲は、個々のホストに限定されることがあります。また、LDAP などのネームサービスからサービスを受けるすべてのホストが適用範囲に含まれることもあります。あるシステムのネームサービスの適用範囲は、ネームスイッチサービス svc:/system/name-service/switch で指定されます。検索は、最初に一致した時点で停止します。たとえば、権利プロファイルが 2 つのネームサービススコープに存在する場合、最初のネームサービススコープに含まれるエントリだけが使用されます。最初に一致したものが files の場合、役割の適用範囲はローカルホストに限定されます。
一般にユーザーは、役割を通して管理権限を取得します。承認、特権、および特権付きコマンドは、権利プロファイルにグループ化されます。権利プロファイルは役割に含められ、役割がユーザーに割り当てられます。
権利プロファイルとセキュリティー属性を直接割り当てることも可能です。
ユーザーには、権利プロファイル、特権、および承認を直接割り当てることができます。
役割とユーザーには、特権と承認を直接割り当てることができます。
しかし、特権の割り当てを直接行うことは安全とは言えません。特権が直接割り当てられたユーザーと役割は、カーネルがその特権を要求するどの場合でもセキュリティーポリシーに優先します。安全なやり方は、特権をコマンドのセキュリティー属性として権利プロファイル内で割り当てる方法です。そうすると、その特権は、その権利プロファイルを持つユーザーが、そのコマンドでのみ使用できます。
承認はユーザーレベルで作用するため、承認の直接割り当ては特権の直接割り当てよりリスクが小さいと言えます。しかし、承認が与えられることで、ユーザーは監査フラグの割り当てなどの高いセキュリティーが求められるタスクも実施できるようになります。
権利プロファイルやセキュリティー属性を直接割り当てると、操作性に影響を与えることがあります。
直接割り当てられた特権や承認、および直接割り当てられた権利プロファイル内のコマンドや承認は、有効にするためにプロファイルシェルで解釈する必要があります。デフォルトでは、ユーザーにはプロファイルシェルが割り当てられません。
ユーザーは忘れずにプロファイルシェルを開き、そのシェルでコマンドを実行する必要があります。
承認を個々に割り当てる方法には拡張性がありません。さらに、直接割り当てられた承認は、タスクを実行するには十分でない可能性があります。タスクに特権付きコマンドが必要な場合もあります。
権利プロファイルは、承認と特権付きコマンドをまとめるように設計されています。また、この方法には拡張性もあります。
|