機能説明

ドキュメントの品質向上のためのご意見をください

Your rating has been updated

貴重なご意見を有り難うございました!

あなたの貴重なご意見はより良いドキュメント作成の手助けとなります内容の品質向上と追加コメントのためのアンケートに参加されますか？

rbac

, RBAC

- 役割に基づくアクセス制御

役割に基づくアクセス制御を使用すると、システム管理者は、システムの各部分の管理制御をユーザーに委任できます。ユーザーが追加の特権を使用してコマンドを実行できるようにするための方法には、次の 2 つがあります:

ユーザーにプロファイルを直接割り当てます。この場合、追加の認証は必要ありません
役割を作成し、その役割にプロファイルを割り当てます。また、このアクセス制御を使用すると、通常であれば実行を許可されるコマンドを実行できなくすることにより、ユーザーにとって制限的な環境を構築することもできます。

プロファイル

プロファイルは、追加の特権または特定の実 UID/GID や実効 UID/GID、あるいはその両方で実行されるコマンドおよび承認の名前付き集合です。たとえば、ほとんどのプリンタシステムは、lp コマンドを UID または lp で実行することによって管理できます。一部のコマンドの実行には、privileges(5) で定義された特権が必要です。たとえば、「Process Management」プロファイルを使用すると、ユーザーは、所有していないプロセスにシグナルを送信できるように proc_owner 特権で kill コマンドを実行できます。

管理者がシステムで提供されたプロファイルを拡張したり、独自のプロファイルを作成したりする方法については、exec_attr(4) および prof_attr(4) を参照してください。プロファイルの構成は、現在サポートされているネームサービス (ファイル、NIS、LDAP) のいずれかに格納できます。

プロファイルはまた、サービスの実行に使用される特権や UID/GID を制御するためにサービス管理機能 (SMF) でも使用できます。詳細は、smf_security(5) を参照してください。

役割

役割は、承認ユーザーが su(1M) コマンドで、またはホストベース認証や GSS-API 認証を使用している場合は ssh(1) でネットワーク経由でしかアクセスできないシステムに直接ログインすることができない特殊な共有アカウントです。役割は、rlogin(1)、telnet(1)、または gdm ではログインできません。

役割には、通常ユーザーと同様に UID、パスワード、およびホームディレクトリがあります。役割に対する認証は、ユーザー独自のパスワードまたは役割ごとのパスワードのどちらかで行うことができます (user_attr(4) の roleauth キーワードによって、その動作が役割ごとに制御されます)。通常、役割のログインシェルは、1 つ以上のプロファイルが付与されることによって役割が常に特権でコマンドを実行できるようにするプロファイルシェル (pfsh(1)、pfksh(1)、pfcsh(1)) のいずれかです。

役割は通常、共有アカウント環境が必要な場合にのみ必要になります。通常は、ユーザーにプロファイルを直接割り当てれば十分です。

root ユーザーは、usermod(1M) コマンドを使用すると役割として構成できます。これにより、root パスワードがより広範囲に知られている場合でも、承認ユーザーのみが root になれることが保証されます。

# usermod -K type=role root

root を役割にしても、シングルユーザーモードへのアクセスは制限されません。システムコンソールは、eeprom(1M) でのセキュリティーパスワードの設定などの、ほかの手段を使用して保護するようにしてください。

承認

承認は、一部の操作または操作のクラスを実行するためのユーザーの権利を表す一意の文字列です。承認は通常、常に何らかの特権で実行されるプログラム (たとえば、cdrw(1) などの setuid(2) プログラムや、システムの cron(1M) デーモン) によってのみチェックされます。

承認の定義は、auth_attr(4) データベースに格納されます。プログラミングでの承認チェックの場合は、承認名のみが重要です。

auth_attr データベース内のいくつかの代表的な値を次に示します:

solaris.jobs.:::Cron and At Jobs::help=JobHeader.html
solaris.jobs.grant:::Delegate Cron & At \
    Administration::help=JobsGrant.html
solaris.jobs.admin:::Manage All Jobs::help=AuthJobsAdmin.html
solaris.jobs.user:::Cron & At User::help=JobsUser.html

grant 接尾辞で終わる承認名文字列は、ユーザーが、同じ接頭辞と機能領域を持つ承認をほかのユーザーに委任できるようにする特殊な承認です。

solaris で始まる承認名はすべて、オペレーティングシステムのベンダーによる割り当てのために予約されています。開発者と管理者は、独自の最上位の名前空間を作成できます (会社名、DNS ドメイン名、アプリケーション名などの一意の識別子を使用することをお勧めします)。

承認のチェック

C コードから承認をチェックするには、開発者は、ユーザーに特定の承認が割り当てられているかどうかを検証する chkauthattr(3C) ライブラリ関数を使用するようにしてください。

承認は、auths(1) ユーティリティーの出力をチェックすることによって、シェルスクリプトで明示的にチェックできます。たとえば、

for auth in `auths      | tr , " "` NOTFOUND
do
    ["$auth" = "solaris.date" ] && break      # authorization found
done

if [ "$auth" != "solaris.date" ]
then
    echo >&2 "$PROG: ERROR: you are not authorized to set the date"
    exit 1
fi

承認はまた、どのユーザーがサービスの状態を変更したり、サービスを再構成したりできるかを制御するためにサービス管理機能 (SMF) でも使用されます。詳細は、smf_security(5) を参照してください。

sudo(1M) との比較

Solaris の RBAC には、UNIX または UNIX ライクなシステムには多くの場合、用意されている sudo(1M) に似た一連の機能が用意されています。これは Solaris の Companion CD で提供されています。

Solaris RBAC と sudo のもっとも明らかな相違点の 1 つが認証モデルです。sudo では、ユーザーは自分自身として再認証します。Solaris RBAC では、追加の認証が必要ないか (ユーザーにプロファイルが直接割り当てられている場合)、またはユーザーが、役割と呼ばれる共有アカウントから認証されるかのどちらかです。

sudo での NOPASSWD 機能の使用は、ユーザーにプロファイルを割り当て、ユーザーが pfexec(1) を使用してコマンドを実行するようにする方法と同様です。たとえば、sudoers(4) で、ユーザーが UID 0 として kill(1) を認証なしで (NOPASSWD) 実行できるようにする場合、ユーザーは次を実行します:

$ sudo kill -HUP 1235

Solaris RBAC では、ユーザーに通常の (つまり、プロファイルなしの) ログインシェルが割り当てられている場合、ユーザーは「Process Management」プロファイルが割り当てられることにより同等の操作を実行し、次のように pfexec を使用します:

$ pfexec kill -HUP 1235

ユーザーにログインシェルとして (pfsh などの) プロファイルシェルが割り当てられている場合は、「接頭辞」がなくても kill は常に追加の特権で実行されます。たとえば、

$ kill -HUP 1235

RBAC の役割は、ユーザーパスワードではなく役割のパスワードが必要な点を除き、概念的には sudoers(4) の User_Alias に似ています。

RBAC の実行プロファイル (exec_attr(4) エントリ) は、sudoers の Cmnd_Alias に似ています。

現在、Solaris RBAC には Host_Alias sudo(1M) と同等の機能はありません。

ナビゲーションリンクをスキップ
印刷ビューの終了
	マニュアルページセクション 5: 標準、環境、マクロ Oracle Solaris 11.1 Information Library (日本語)