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

マシンの情報のセキュリティーを保つことは、重要なシステム管理作業です。この章では、マシンセキュリティー管理の概要を説明します。

この章の内容は次のとおりです。

• 「Solaris 10 リリースにおけるマシンセキュリティーの向上」

• 「コンピュータシステムへのアクセスを制御する」

• 「デバイスアクセスの制御」

• 「マシンリソースへのアクセス制御」

• 「ファイルアクセスの制御」

• 「ネットワークアクセスの制御」

• 「セキュリティー問題の報告」

Solaris 10 リリースにおけるマシンセキュリティーの向上

Solaris 9 のリリース以降、システムセキュリティーを向上させるために次の機能が追加されました。

• 強力なパスワード暗号化機能を利用できます。この機能はユーザーによる設定が可能です。詳細は、「パスワードの暗号化」を参照してください。

• デバイスポリシーが特権によって強化されました。詳細は、「デバイスポリシー (概要)」を参照してください。

  デバイス割り当てについては、今後の Solaris OS リリースで /etc/security/dev ディレクトリがサポートされなくなる可能性があります。

• 基本監査報告機能 (BART) は、システム上のファイルの信頼性を監視するために使用できます。詳細は、第 5 章基本監査報告機能の使用方法 (作業)を参照してください。

• 強力な暗号化でファイルを保護できるようになりました。詳細は、「暗号化によるファイルの保護」を参照してください。

• 特権により、カーネルレベルでプロセスの権限を指定できるようになりました。詳細は、「特権 (概要)」を参照してください。

• Solaris 暗号化フレームワークにより、プロバイダやコンシューマを対象にした暗号化サービスが一元化できるようになりました。詳細は、第 13 章Solaris の暗号化フレームワーク (概要)を参照してください。

• PAM フレームワークで、さまざまなプログラムに対応できる機能 (Solaris Secure Shell など) が提供されました。詳細は、「Solaris 10 リリースにおける PAM への変更」を参照してください。

• マシンリソースに対して Solaris ゾーンの指定やリソース管理制御アクセスが行えるようになりました。詳細については、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』を参照してください。

コンピュータシステムへのアクセスを制御する

ワークスペースでは、サーバーに接続されたすべてのマシンを 1 つの大規模多重システムと見なすことができます。システム管理者は、この大規模なシステムのセキュリティー管理に責任があります。システム管理者は、ネットワークの外部からの侵入を防ぐ必要があります。また、ネットワーク内部のマシン上のデータの完全性を確保する必要もあります。

ファイルレベルにおいて、Solaris OS には標準セキュリティー機能が組み込まれており、ファイル、ディレクトリ、およびデバイスを保護するために使用できます。システムレベルとネットワークレベルでは、セキュリティーの内容はほぼ同じです。セキュリティー防御の第一線は、システムへのアクセスを制御することです。

次の方法でシステムへのアクセスを制御または監視できます。

• 「物理的なセキュリティーの管理」

• 「ログイン制御の管理」

• 「デバイスアクセスの制御」

• 「マシンリソースへのアクセス制御」

• 「ファイルアクセスの制御」

• 「ネットワークアクセスの制御」

• 「セキュリティー問題の報告」

物理的なセキュリティーの管理

システムへのアクセスを制御するには、コンピュータ環境の物理的なセキュリティーを管理する必要があります。たとえば、システムにログインしたままこれを放置することは未承認アクセスを招く原因になります。侵入者がオペレーティングシステムやネットワークにアクセスしないとも限らないからです。コンピュータの周辺環境やコンピュータハードウェアは、不当なアクセスから物理的に保護する必要があります。

システム管理者は、ハードウェア設定に対する不当なアクセスから SPARC システムを保護することができます。eeprom コマンドを使って、パスワードがないと PROM にアクセスできないようにしてください。詳細は、「ハードウェアアクセスのパスワードを必須にする方法」を参照してください。

ログイン制御の管理

システムやネットワークへの無許可のログインも防止する必要があります。この制限は、パスワード割り当てとログイン制御によって行うことができます。システム上のすべてのアカウントには、パスワードを設定します。パスワードはシンプルな認証メカニズムです。アカウントにパスワードを設定しないと、ユーザー名を推測できる侵入者であれば誰でもネットワーク全体にアクセスできることになります。力ずくの野蛮な攻撃を許さないためには、強力なパスワードアルゴリズムが必要です。

ユーザーがシステムにログインすると、login コマンドは /etc/nsswitch.confファイル内の情報に従って、該当するネームサービスまたはディレクトリサービスのデータベースを照会します。このファイルには次のエントリを含めることができます。

• files – ローカルシステムの /etc ファイルを指定します

• ldap – LDAP サーバーの LDAP ディレクトリサービスを指定します

• nis – NIS マスターサーバーの NIS データベースを指定します

• nisplus – NIS+ root サーバーの NIS+ データベースを指定します

nsswitch.conf ファイルの詳細は、nsswitch.conf(4) のマニュアルページを参照してください。ネームサービスおよびディレクトリサービスについては、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』または『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

login コマンドは、指定されたユーザー名とパスワードを検証します。ユーザー名がパスワードファイルにないと、login コマンドはシステムへのアクセスを拒否します。あるいは、指定されたユーザー名に対するパスワードが正しくないと、login コマンドはシステムへのアクセスを拒否します。有効なユーザー名とそれに対応するパスワードが入力されれば、システムはシステムへのアクセスをユーザーに認可します。

PAM モジュールには、システムへのログインが正常に完了したあとでアプリケーションへのログインをスムーズに行わせる効果があります。詳細については、第 17 章PAM の使用を参照してください。

Solaris システムには、精巧な認証メカニズムと承認メカニズムが備わっています。ネットワークレベルでの認証メカニズムや承認メカニズムについては、「遠隔アクセスの認証と承認」を参照してください。

パスワード情報の管理

ユーザーはシステムにログインするときに、ユーザー名とパスワードの両方を入力する必要があります。ログイン名は公開されていますが、パスワードは秘密にしなければなりません。ユーザーは、自分のパスワードを他人に知られてはいけません。また、各自のパスワードを慎重に選択し、頻繁に変更するようにしなければなりません。

パスワードは、最初にユーザーアカウントを設定するときに作成されます。ユーザーアカウントのセキュリティーを管理するために、パスワード有効期限を設定し、パスワードを定期的に強制変更することができます。また、ユーザーアカウントを無効にして、パスワードをロックすることもできます。パスワードの管理の詳細については、『Solaris のシステム管理 (基本編)』の第 4 章「ユーザーアカウントとグループの管理 (概要)」と、passwd(1) のマニュアルページを参照してください。

ローカルパスワード

ネットワークでローカルファイルを使用してユーザーの認証を行なっている場合、パスワード情報はシステムの /etc/passwd ファイルと /etc/shadow ファイルに保持されます。ユーザー名などの情報は、パスワードファイル /etc/passwd に保持されます。暗号化されたパスワードは、/etc/shadow という「シャドウ」ファイルに保持されます。このセキュリティー方式によって、暗号化されたパスワードにアクセスされることを防ぎます。/etc/passwd ファイルは、システムにログインするユーザーであれば誰でも使用できますが、/etc/shadow ファイルを読み取ることができるのはスーパーユーザー、またはスーパーユーザーと同等の役割だけです。passwd コマンドを使用すると、ローカルシステム上のユーザーのパスワードを変更できます。

NIS パスワードおよび NIS+ パスワード

ネットワークで NIS を使用してユーザーの認証を行なっている場合、パスワード情報は NIS パスワードマップに保持されます。NIS では、パスワードの有効期間を指定できません。NIS パスワードマップに保持されているユーザーのパスワードを変更するには、コマンド passwd -r nis を使用します。

ネットワークで NIS+ を使用してユーザーの認証を行っている場合、パスワード情報は NIS+ データベースに保持されます。NIS+ データベース内の情報は、承認されたユーザーだけにアクセスを制限することによって保護できます。NIS+ データベースに保持されているユーザーのパスワードを変更するには、passwd -r nisplus コマンドを使用します。

LDAP パスワード

Solaris の LDAP ネーミングサービスは、パスワード情報とシャドウ情報を LDAP ディレクトリツリーの ou=people コンテナに格納します。Solaris LDAP ネーミングサービスクライアントでユーザーのパスワードを変更するには、passwd -r ldap コマンドを使用します。LDAP ネーミングサービスは、パスワードを LDAP リポジトリに格納します。

パスワードポリシーは、Sun Java System Directory Server 上で適用されます。つまり、クライアントの pam_ldap モジュールは、Sun Java System Directory Server で適用されているパスワードポリシー制御に従います。詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「LDAP ネームサービスのセキュリティーモデル」を参照してください。

パスワードの暗号化

パスワードの強力な暗号化は攻撃に対する最初の障壁になります。Solaris ソフトウェアには、4 つのパスワード暗号化アルゴリズムがあります。2 つの MD5 アルゴリズムと Blowfish アルゴリズムでは、UNIX アルゴリズムよりも強力なパスワードの暗号化が行われます。

パスワードアルゴリズムの識別子

サイトのアルゴリズムの構成は、/etc/security/policy.conf ファイルに指定します。policy.conf ファイルには、次の表に示す識別子でアルゴリズムを指定します。

policy.conf ファイルのアルゴリズム構成

次に、policy.conf ファイルに指定されたデフォルトのアルゴリズム構成を示します。

#
…
# crypt(3c) Algorithms Configuration
#
# CRYPT_ALGORITHMS_ALLOW specifies the algorithms that are allowed to
# be used for new passwords.  This is enforced only in crypt_gensalt(3c).
#
CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6

# To deprecate use of the traditional unix algorithm, uncomment below
# and change CRYPT_DEFAULT= to another algorithm.  For example,
# CRYPT_DEFAULT=1 for BSD/Linux MD5.
#
#CRYPT_ALGORITHMS_DEPRECATE=__unix__

# The Solaris default is the traditional UNIX algorithm.  This is not
# listed in crypt.conf(4) since it is internal to libc.  The reserved
# name __unix__ is used to refer to it.
#
CRYPT_DEFAULT=__unix__
…

CRYPT_DEFAULT の値を変更すると、新しいユーザーのパスワードは、新しい値に対応するアルゴリズムを使って暗号化されます。現在のユーザーがパスワードを変更したときに新しいパスワードがどのアルゴリズムで暗号化されるかは、古いパスワードがどのように暗号化されているかによって異なります。

たとえば、CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6 かつ CRYPT_DEFAULT=1 であるとします。次の表は、パスワードの暗号化にどのアルゴリズムが使用されるかを示します。

選択したアルゴリズムの構成の詳細については、policy.conf(4) のマニュアルページを参照してください。パスワード暗号化アルゴリズムを指定する方法については、「パスワードアルゴリズムの変更 (作業マップ)」 を参照してください。

特別なシステムログイン

システムにアクセスする一般的な方法としては、通常のユーザーログインを使用するものと、root ログインを使用するものがあります。また、多数の特別な「システム」ログインを使用すると、ユーザーは root アカウントを使用しなくても管理コマンドを実行できます。システム管理者は、これらのログインアカウントにパスワードを割り当てます。

次の表に、システムのログインアカウントとその用途を示します。システムログインは特殊な機能を実行します。それぞれのログインに固有のグループ識別番号 (GID) が付いています。各ログインには固有のパスワードを設定し、必要のある人だけに知らせるようにしてください。

遠隔ログイン

侵入者にとって、遠隔ログインは魅力的な手段です。Solaris OS には、遠隔ログインを監視、制限、および無効にするコマンドがいくつもあります。手順については、「ログインとパスワードの保護 (作業マップ)」を参照してください。

デフォルトでは、システムのマウスやキーボード、フレームバッファー、オーディオデバイスなど、特定のシステムデバイスを、遠隔ログインを通して制御したり読み取ったりすることはできません。詳細は、logindevperm(4) のマニュアルページを参照してください。

ダイヤルアップログイン

モデムやダイヤルアップポートを通してアクセスされうるコンピュータには、セキュリティー層をもう 1 つ追加できます。つまり、モデムやダイヤルアップポートを通してシステムにアクセスするユーザーには「ダイヤルアップパスワード」を要求することができます。ダイヤルアップパスワードは、ユーザーがシステムへのアクセス権を取得する前に指定する必要があります。

ダイヤルアップパスワードの作成または変更が行えるのは、スーパーユーザー、またはスーパーユーザーと同等の役割だけです。システムの完全性を確保するために、月に一度はパスワードを変更する必要があります。この機能のもっとも有効な使用方法は、ゲートウェイシステムへのアクセス権を取得するためのダイヤルアップパスワードを要求することです。ダイヤルアップパスワードの設定方法については、「ダイヤルアップパスワードを作成する方法」を参照してください。

ダイヤルアップパスワードの作成には、/etc/dialups と /etc/d_passwd という 2 つのファイルが必要です。dialups ファイルには、ダイヤルアップパスワードを必要とするポートのリストを含みます。d_passwd ファイルには、追加のダイヤルアップパスワードとして暗号化パスワードを必要とするシェルプログラムのリストを含みます。これら 2 つのファイルの情報は次のように処理されます。

• /etc/passwd 内のユーザーのログインシェルが /etc/d_passwd 内のエントリと一致する場合、そのユーザーはダイヤルアップパスワードを入力する必要があります。

• /etc/passwd 内のユーザーのログインシェルが /etc/d_passwd 内で見つからない場合、そのユーザーはデフォルトのパスワードを入力する必要があります。デフォルトのパスワードは /usr/bin/sh のエントリです。

• /etc/passwd 内のログインシェルフィールドが空の場合、そのユーザーはデフォルトのパスワードを入力する必要があります。デフォルトのパスワードは /usr/bin/sh のエントリです。

• /etc/d_passwd に /usr/bin/sh のエントリがない場合、/etc/passwd 内のログインシェルフィールドが空のユーザー、または /etc/d_passwd 内のエントリと一致しないユーザーには、ダイヤルアップパスワードの入力を求めるプロンプトは表示されません。

• /etc/d_passwd ファイルのエントリが /usr/bin/sh:*: だけである場合、ダイヤルアップログインは無効です。

デバイスアクセスの制御

コンピュータシステムに接続された周辺機器は、セキュリティーリスクをもたらします。たとえば、マイクは会話をキャッチし、その会話を遠隔システムに送信します。CD-ROM の場合、その情報を CD-ROM に残して、CD-ROM デバイスを次に使うユーザーが読み取れるようにすることができます。プリンタは、遠隔サイトからもアクセスできます。システムの必須デバイスもまた、セキュリティー問題を引き起こす可能性があります。たとえば、hme0 のようなネットワークインタフェースは不可欠なデバイスとみなされています。

Solaris ソフトウェアには、デバイスアクセスを制御する方法が 2 つ用意されています。「デバイスポリシー」は、システムに不可欠なデバイスに対するアクセスの制限または防止を行うものです。デバイスポリシーはカーネル内で適用されます。「デバイス割り当て」は、周辺機器に対するアクセスの制限または防止を行う作業です。デバイス割り当ては、ユーザー割り当ての時点で適用されます。

デバイスポリシーは、特権を使用して特定のデバイスをカーネル内で保護します。たとえば、ネットワークインタフェースのデバイスポリシー (hme など) は、読み取りまたは書き込みに対してすべての権限を要求します。

デバイス割り当ては、承認を利用してプリンタやマイクなどの周辺機器を保護します。デフォルトでは、デバイス割り当ては無効な状態になっています。デバイス割り当てが有効な状態では、この構成を変更してデバイスの使用を防いだり、デバイスアクセスに承認が必要なように設定したりできます。デバイスの使用割り当てが行われると、現在のユーザーがその割り当てを解除するまでほかのユーザーはそのデバイスにアクセスできません。

デバイスアクセスを制御する手段として、次に示すようないくつかの方法で Solaris システムを構成できます。

• デバイスポリシーを設定する – Solaris OS では、特定のデバイスにプロセスがアクセスする場合、そのプロセスが特定の権限のもとで実行されていることを必要条件とすることができます。それらの権限を持たないプロセスは、そのデバイスを使用できません。起動時に、Solaris ソフトウェアはデバイスポリシーを設定します。Sun 以外のドライバは、そのインストール時にデバイスポリシーを組み込むことができます。インストール後、システム管理者はデバイスポリシーをデバイスに追加できます。

• デバイスを割り当て可能にする – デバイス割り当てを有効にする際には、一度に 1 人しかそのデバイスを使用できないように制限できます。また、ユーザーが何らかのセキュリティー要件を満たすように要求することも可能です。たとえば、そのデバイスを使用する承認を得ていることを要求できます。

• デバイスの使用を防ぐ – コンピュータシステム上のどのユーザーも特定のデバイス (マイクなど) を使用できないように設定できます。特定のデバイスを使用できない状態にする例としては、コンピュータキオスクが挙げられます。

• デバイスを特定のゾーンに限定する – デバイスの使用を非大域ゾーンにだけ割り当てることができます。詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の「非大域ゾーンでのデバイスの使用」を参照してください。デバイスとゾーンに関する一般的な説明は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の「ゾーンで構成されるデバイス」を参照してください。

デバイスポリシー (概要)

デバイスポリシーメカニズムを使用することで、デバイスを開こうとするプロセスに特定の権限を要求するように指定できます。デバイスポリシーによって保護されたデバイスをアクセスできるのは、デバイスポリシーで指定されている権限で稼働しているプロセスだけです。Solaris OS には、デフォルトのデバイスポリシーが用意されています。たとえば、hme0 などのネットワークインタフェースは、インタフェースにアクセスするプロセスが net_rawaccess 権限で稼働していることを必要とします。この要件はカーネルで適用されます。特権の詳細は、「特権 (概要)」を参照してください。

以前の Solaris OS リリースでは、デバイスノードの保護はファイルアクセス権だけで行われました。たとえば、グループ sys が所有しているデバイスをオープンできるのはこのグループのメンバーだけでした。デバイスを開くことができるユーザーをアクセス権が予測することはありません。デバイスは、ファイルアクセス権によって保護されるとともに、デバイスポリシーでも保護されます。たとえば、/dev/ip ファイルのアクセス権は 666 です。しかし、このデバイスは適切な権限を持つプロセスによってしかオープンできません。

デバイスポリシーの設定は監査の対象とすることができます。デバイスポリシーの変更は、AUE_MODDEVPLCY 監査イベントによって記録されます。

デバイスポリシーの詳細は、次のページを参照してください。

• 「デバイスポリシーの設定 (作業マップ)」

• 「デバイスポリシーコマンド」

• 「特権とデバイス」

デバイス割り当て (概要)

デバイス割り当てメカニズムを使用すれば、CD-ROM などの周辺機器に対するアクセスを制限できます。このメカニズムは、システム管理者によってローカルに管理されます。デバイス割り当てが有効になっていない場合、周辺機器の保護はファイルアクセス権によってのみ行われます。たとえば、デフォルトでは周辺機器は次のように使用できます。

• すべてのユーザーがフロッピーディスクや CD-ROM の読み取りと書き込みが行えます。

• すべてのユーザーがマイクを接続できます。

• すべてのユーザーが接続されたプリンタにアクセスできます。

デバイス割り当てを行うことで、承認されたユーザーにだけデバイスの使用を限定できます。デバイス割り当てによって、デバイスアクセスを完全に防ぐこともできます。デバイスを割り当てるユーザーは、そのユーザー自身が割り当てを解除するまでそのデバイスを独占的に使用できます。デバイスの割り当てが解除される際には、残っているすべてのデータがデバイスクリーンスクリプトによって消去されます。デバイスにスクリプトがない場合には、デバイスクリーンスクリプトを作成してそのデバイスから情報を一掃できます。この例は、「新しいデバイスクリーンスクリプトの作成」を参照してください。

デバイス割り当てに関連した試み (デバイスの割り当て、デバイスの割り当て解除、割り当て可能なデバイスの一覧表示) は、監査の対象とすることができます。監査イベントは、ot 監査クラスの一部です。

デバイス割り当ての詳細は、次のページを参照してください。

• 「デバイス割り当ての管理 (作業マップ)」

• 「デバイスの割り当て」

• 「デバイス割り当てコマンド」

マシンリソースへのアクセス制御

システム管理者は、システム活動の制御や監視を行うことができます。システム管理者は、だれがどのリソースを使用できるかを制限したり、リソースの使用状況を記録したり、だれがリソースを使用しているかを監視したりできます。さらに、システム管理者は、リソースの不適切な使用を最小限に抑えるようにマシンを設定できます。

スーパーユーザーの制限と監視

システムでスーパーユーザーアクセスを行うには、root パスワードが必要です。デフォルトの構成では、ユーザーは遠隔からシステムに root としてログインできません。遠隔ログインするとき、ユーザーは自分のユーザー名でログインしてから、su コマンドを使用して root になる必要があります。管理者は、必要に応じて su コマンドを使用中のユーザー (特にスーパーユーザーのアクセス権を取得しようとしているユーザー) を監視できます。スーパーユーザーを監視したり、スーパーユーザーのアクセス権を制限したりする手順については、「スーパーユーザーの監視と制限 (作業マップ)」を参照してください。

役割によるアクセス制御を構成してスーパーユーザーを置き換える

役割によるアクセス制御 (RBAC) は、スーパーユーザーの権限を制限することを目的として設計されています。スーパーユーザーすなわち root ユーザーは、システムのすべてのリソースにアクセスできますが、RBAC を使用すれば、スーパーユーザーの権限を個別の権限からなる役割の集合に置き換えることができます。たとえば、ユーザーアカウントの作成を行う役割やシステムファイルの変更を行う役割を個別に設定できます。特定の機能または機能群を扱う役割を設定したら、これらの機能をroot の機能から取り除くことができます。

個々の役割を引き受けるためには、既存のユーザーが自分のユーザー名とパスワードを使ってログインする必要があります。ログインしたユーザーは、特別な役割パスワードを入力してその役割を引き受けます。これによって、他人が root パスワードを知ったとしても、システムに損傷を与える能力は限定されます。RBAC の詳細は、「役割によるアクセス制御 (概要)」を参照してください。

マシンリソースの意図しない使用の防止

システム管理者は、自分自身やユーザーによって意図しないエラーが引き起こされないように防止できます。

• たとえば、PATH 変数を正しく設定することによって、トロイの木馬の実行を防止できます。

• 制限されたシェルをユーザーに割り当てることもできます。システムのうち各人の作業に必要な部分だけをユーザーに提供するという方法でシェル機能を制限すると、ユーザーエラーを避けることができます。実際、慎重に設定すれば、作業を能率的に行う上で必要な部分以外にユーザーがアクセスできないように制限できます。

• そのユーザーがアクセスする必要がないファイルには、限定的なアクセス権を設定できます。

PATH 変数の設定

PATH 変数を正しく設定しないと、他人が持ち込んだプログラムを誤って実行し、データを壊したりシステムを損傷したりするおそれがあります。このようなプログラムはセキュリティー上の危険を招くので、「トロイの木馬」と呼ばれます。たとえば、公開ディレクトリの中に別の su プログラムが置かれていると、システム管理者が気づかずに実行してしまう可能性があります。このようなスクリプトは正規の su コマンドとまったく同じに見えます。このようなスクリプトは実行後に自らを削除してしまうため、トロイの木馬が実際に実行されたという証拠はほとんど残りません。

PATH 変数はログイン時に自動的に設定されます。パスは、起動ファイル、すなわち .login、.profile、および .cshrc を通して設定されます。現在のディレクトリ (.) への検索パスを最後に指定すれば、トロイの木馬のようなタイプのプログラムを実行するのを防ぐことができます。スーパーユーザーの PATH 変数には、現在のディレクトリを指定しないでください。

自動セキュリティー拡張ツール (ASET) は、起動ファイルの PATH 変数が正しく設定されているかどうかを調べます。また、PATH 変数にドット (.) エントリが含まれていないか確認します。

ユーザーに制限付きシェルを割り当てる

標準シェルを使用すると、ユーザーはファイルを開く、コマンドを実行するなどの操作を行うことができます。制限付きシェルを使用すると、ディレクトリの変更やコマンドの実行などのユーザー能力を制限できます。制限付きシェルは、/usr/lib/rsh コマンドで呼び出されます。制限付きシェルは、遠隔シェル /usr/sbin/rsh ではありません。

標準のシェルと異なる点は次のとおりです。

• ユーザーはホームディレクトリ内に限定されるため、 cd コマンドを使用してディレクトリを変更できません。したがって、システムファイルを閲覧することはできません。

• ユーザーは PATH 変数を変更できないため、システム管理者によって設定されたパスのコマンドしか使用できません。さらに、完全なパス名を使ってコマンドやスクリプトを実行することもできません。

• ユーザーは、> または >> を使用して出力をリダイレクトできません。

制限付きシェルでは、ユーザーが使用できるシステムファイルを制限できます。このシェルは、特定のタスクを実行するユーザーのために限られた環境を作成します。ただし、制限付きシェルは完全に安全なわけではありません。このシェルの目的は、あくまでも、経験の少ないユーザーが誤ってシステムファイルを損傷するのを防止することです。

制限付きシェルについては、rsh(1M) のマニュアルページを参照してください。このマニュアルページは、man -s1m rsh コマンドで表示できます。

ファイル内のデータへのアクセス制限

Solaris OS はマルチユーザー環境なので、ファイルシステムのセキュリティーは、システムのもっとも基本的な問題です。ファイルの保護には、従来の UNIX のファイル保護と、より確実なアクセス制御リスト (ACL) との両方が使用できます。

一部のユーザーには特定のファイルの読み取りを許可し、別のユーザーには特定のファイルを変更または削除するアクセス権を与えることができます。一方、あるデータを、どのユーザーからも読み取られないよう設定することもできます。ファイルのアクセス権の設定方法については、第 6 章ファイルアクセスの制御 (作業)を参照してください。

setuid 実行可能ファイルの制限

実行可能ファイルがセキュリティーリスクとなる場合があります。多くの実行可能プログラムは、スーパーユーザー (root) として実行しなければ適切に動作しません。これらの setuid プログラムは、ユーザー ID が 0 に設定された状態で実行されます。このようなプログラムはだれが実行したとしても root ID で実行されます。root ID で動作するプログラムは、プログラムがセキュリティーを念頭に置いて作成されていない限り、セキュリティーの問題をはらんでいます。

Sun が setuid ビットを root に設定して出荷する実行可能プログラムを除き、setuid プログラムの使用を許可するべきではありません。setuid プログラムの使用を禁止できない場合は、少なくともその使用を制限するべきです。しっかりした管理を行うためには setuid プログラムの数を少なくする必要があります。

詳細は、「実行可能ファイルを原因とするセキュリティーへの悪影響を防止する」を参照してください。作業手順については、「セキュリティーリスクのあるプログラムからの保護 (作業マップ)」を参照してください。

自動セキュリティー拡張ツールの使用

ASET セキュリティーパッケージには、システムのセキュリティーを制御して監視できるように、自動管理ツールが組み込まれています。ASET には、 低、中、高という 3 つのセキュリティーレベルがあります。システム管理者は ASET セキュリティーレベルを指定します。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセス は減少し、システムセキュリティーが厳しくなります。詳細は、第 7 章自動セキュリティー拡張ツールの使用 (手順)を参照してください。

Sun Security Toolkit の使用

ASET はシステムにセキュリティー上のわずかな変更を加えるのに使用できますが、Sun Security Toolkit は Solaris システムの最小化、強化、保護などに対応できる、柔軟で、拡張性のあるメカニズムです。Sun Security Toolkit (旧名称: JASS ツールキット) は、システムにセキュリティー変更を加えるためのツールです。このツールを使用して、システムのセキュリティー状態に関するレポートを生成できます。このツールには、ツールの直前の実行を取り消す機能もあります。JASS ツールキットは、Sun の Web サイト http://www.sun.com/software/security/jass からダウンロードできます。この Web サイトでは、関連するオンラインドキュメントもリンクされています。

このツールキットの詳細は、『Securing Systems with the Solaris Security Toolkit』(Alex Noordergraaf、Glenn Brunette 共著、ISBN 0-13-141071-7、2003 年 6 月発行) を参照してください。このドキュメントは、Sun Microsystems Press によって発行されている Sun BluePrints Series の 1 つです。

netservices limited 構成の使用

デフォルトでは、Solaris 10 リリースのインストール時に多数のネットワークサービスが有効になります。システムのネットワーク接続を制限するには、netservices limited コマンドを実行します。このコマンドは、「デフォルトでのセキュリティー強化 (Secure By Default)」(SBD) 構成を有効にします。SBD により、ネットワーク要求を受け付けるネットワークサービスは sshd デーモンだけになります。ほかのネットワークサービスはすべて無効になるか、ローカル要求だけを処理するようになります。ftp などの個々のネットワークサービスを有効にするには、Solaris のサービス管理機能 (SMF) を使用します。詳細は、netservices(1M) および smf(5) のマニュアルページを参照してください。

Solaris のリソース管理機能の使用

Solaris ソフトウェアには、精巧なリソース管理機能があります。これらの機能を使用することで、サーバー統合環境内のアプリケーションによるリソース利用の割り当て、スケジュール、監視、上限設定などを行うことができます。リソース制御フレームワークにより、プロセスが使用するシステムリソースを制限できます。このような制約を行うことで、システムリソースを混乱させようとするスクリプトによるサービス拒否攻撃を防ぎやすくなります。

Solaris リソース管理機能により、特定のプロジェクトに必要なリソースを割り当てたり、使用できるリソースを動的に調整したりできます。詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』のパート I「資源管理」を参照してください。

Solaris ゾーンの使用

Solaris ゾーンは、単一の Solaris OS インスタンス内に存在するほかのシステムからプロセスが分離されるアプリケーション実行環境です。この分離を行うことで、1 つのゾーン内で稼働しているプロセスがほかのゾーンで稼働しているプロセスを監視したりそれらのプロセスに影響を及ぼしたりすることが防止されます。これは、スーパーユーザー権限によって稼働しているプロセスでも同様です。

Solaris ゾーンは、単一のサーバー上にアプリケーションを複数配置する環境に適しています。詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』のパート II「ゾーン」を参照してください。

マシンリソースの使用状況の監視

システム管理者は、システムの動作を監視する必要があります。次の点を含め、マシンのあらゆる側面に注意する必要があります。

• 通常の負荷はどの程度か

• 誰がシステムへのアクセス権を持っているか

• 各ユーザーはいつシステムにアクセスするか

• システムでは通常どのようなプログラムを実行するか

このような情報を把握していれば、ツールを使用してシステムの使用状況を監査し、各ユーザーのアクティビティーを監視できます。セキュリティー侵害と思われる場合は、監視作業が特に役立ちます。監査サービスの詳細は、第 28 章Solaris 監査 (概要) を参照してください。

ファイルの整合性の監視

システム管理者は、管理対象のシステムにインストールされたファイルが予想外の方法で変更されないように確実な対策をとる必要があります。大規模インストールでは、各システム上のソフトウェアスタックの比較や報告を行うツールを使用すればシステムの追跡、記録が行えます。基本監査報告機能 (BART) を使用すると、一定期間にわたって1 つ以上のシステムをファイルレベルでチェックし、システムを包括的に検証できます。一定期間にわたってすべてのシステムまたは 1 つのシステムにおける BART 目録の変化を調べることで、システムの整合性を検証できます。BART には、目録作成機能、目録比較機能、レポート生成規則などが用意されています。詳細は、第 5 章基本監査報告機能の使用方法 (作業)を参照してください。

ファイルアクセスの制御

Solaris OS はマルチユーザー環境です。マルチユーザー環境では、システムにログインしているすべてのユーザーが、ほかのユーザーに属しているファイルを読み取ることができます。さらに、適切なアクセス権をもっているユーザーは、ほかのユーザーに属しているファイルを使用できます。詳細は、第 6 章ファイルアクセスの制御 (作業)を参照してください。ファイルに適切なアクセス権を設定する操作の手順は、「ファイルの保護 (作業マップ)」を参照してください。

暗号化によるファイルの保護

ほかのユーザーがアクセスできないようにすることによって、ファイルを安全に保つことができます。たとえば、アクセス権 600 の付いたファイルに、所有者やスーパーユーザー以外の人がアクセスすることはできません。アクセス権 700 の付いたディレクトリも同様です。ただし、ほかのだれかがユーザーパスワードや root パスワードを推測して発見すると、そのファイルにアクセスできます。さらに、アクセス不能なはずのファイルも、システムファイルのバックアップをオフラインメディアにとるたびに、バックアップテープ上に保存されます。

Solaris 暗号化フレームワークには、ファイルを保護するコマンドとして digest、mac、および encrypt が用意されています。詳細は、第 13 章Solaris の暗号化フレームワーク (概要)を参照してください。

アクセス制御リストの使用

ACL (「アクル」と読む) では、ファイルアクセス権の制御をより強化できます。ACL は、従来の UNIX ファイル保護機能では不十分な場合に追加で使用します。従来の UNIX ファイル保護機能は、 所有者、グループ、その他のユーザーという 3 つのユーザークラスに読み取り権、書き込み権、実行権を提供します。ACL では、ファイルセキュリティーを管理するレベルがさらに詳細になります。

ACL では、次のファイルアクセス権を定義できます。

• 所有者のファイルアクセス権

• 所有者のグループのファイルアクセス権

• 所有者のグループに属していないユーザーのファイルアクセス権

• 特定ユーザーのファイルアクセス権

• 特定グループのファイルアクセス権

• 以上のカテゴリそれぞれのデフォルトアクセス権

ACL の使用についての詳細は、「アクセス制御リストによる UFS ファイルの保護」を参照してください。

マシン間でのファイルの共有

ネットワークファイルサーバーは、どのファイルを共有できるかを制御できます。また、共有ファイルにアクセスできるクライアント、およびそれらのクライアントに許可するアクセス権の種類も制御します。一般に、ファイルサーバーは、すべてのクライアントまたは特定のクライアントに、読み取り権と書き込み権、または読み取り専用アクセス権を与えることができます。アクセス制御は、share コマンドでリソースを利用可能にするときに指定します。

ファイルサーバー上の /etc/dfs/dfstab ファイルは、サーバーがネットワーク上のクライアントに提供するファイルシステムをリストします。ファイルシステムの共有の詳細については、『Solaris のシステム管理 (ネットワークサービス)』の「ファイルシステムの自動共有」を参照してください。

共有ファイルへの root アクセスの制限

一般的にスーパーユーザーは、ネットワーク上で共有されるファイルシステムには root としてアクセスできません。NFS システムは、要求者のユーザーをユーザー ID 60001 を持つユーザー nobody に変更することによって、マウントされているファイルシステムへの root アクセスを防止します。ユーザー nobody のアクセス権は、公共ユーザーに与えられているアクセス権と同じです。つまり、ユーザー nobody のアクセス権は資格をもたないユーザーのものと同じです。たとえば、ファイルの実行権しか公共に許可していなければ、ユーザー nobody はそのファイルを実行することしかできません。

NFS サーバーは、共有ファイルシステムのスーパーユーザー能力をホスト単位で与えることができます。この権限を与えるには、share コマンドの root=hostname オプションを使用します。このオプションは慎重に使用してください。NFS のセキュリティーオプションの詳細は、『Solaris のシステム管理 (ネットワークサービス)』の第 6 章「ネットワークファイルシステムへのアクセス (リファレンス)」を参照してください。

ネットワークアクセスの制御

コンピュータは通常、複数のコンピュータからなる構成の一部です。この構成を「ネットワーク」と呼びます。ネットワークでは、接続されたコンピュータの間で情報を交換できます。さらに、ネットワークに接続されたコンピュータは、ネットワーク上のほかのコンピュータにあるデータなどのリソースにアクセスできます。コンピュータをネットワーク化すると処理能力と性能が向上しますが、同時にセキュリティーの悪化にも繋がります。

たとえば、ネットワーク内では個々のマシンは情報を共有できるため、未承認アクセスがセキュリティーリスクとなります。多くの人々がネットワークにアクセスするので、(特にユーザーエラーを通して) 未承認アクセスが発生する可能性も大きくなります。また、パスワードの不適切な扱いも未承認アクセスの原因となります。

ネットワークセキュリティー機構

一般にネットワークセキュリティーは、遠隔システムからの操作の制限またはブロックを通して維持されます。次の図は、遠隔操作に適用できるセキュリティー制限を示します。

図 2–1 遠隔操作のセキュリティー制限

遠隔アクセスの認証と承認

「認証」とは、遠隔システムにアクセスできるユーザーを特定のユーザーに限定する方法です。認証は、システムレベルでもネットワークレベルでも設定できます。ユーザーが遠隔システムにアクセスすると、「承認」という方法でそのユーザーが実行できる操作が制限されます。次の表は、認証と承認を提供するサービスを示したものです。

Secure RPC に匹敵する機能として、Solaris の「特権ポート」メカニズムがあります。特権ポートには、1024 未満のポート番号が割り当てられます。クライアントシステムは、クライアントの資格を認証したあと、特権ポートを使用してサーバーへの接続を設定します。次に、サーバーは接続のポート番号を検査してクライアントの資格を検証します。

Solaris ソフトウェアを使用していないクライアントは、特権ポートを使用して通信できないことがあります。クライアントが特権ポートを使って通信できない場合は、次のようなエラーメッセージが表示されます。

“Weak Authentication
NFS request from unprivileged port”

ファイアウォールシステム

ファイアウォールシステムを設定すると、ネットワーク内のリソースを外部のアクセスから保護できます。「ファイアウォールシステム」は、内部ネットワークと外部ネットワークの間のバリアとして機能するセキュリティー保護ホストです。内部ネットワークは、ほかのネットワークを「信頼できる状態でない」ものとして扱います。 内部ネットワークと、インターネットなどの外部ネットワークとの間に、このような設定を必ず行うようにしてください。

ファイアウォールはゲートウェイとしても機能しますし、バリアとしても機能します。ファイアウォールは、まず、ネットワーク間でデータを渡すゲートウェイとして機能します。さらに、ファイアウォールは、データが勝手にネットワークに出入りしないようにブロックするバリアとして機能します。ファイアウォールは、内部ネットワーク上のユーザーに対して、ファイアウォールシステムにログインして遠隔ネットワーク上のホストにアクセスするように要求します。また、外部ネットワーク上のユーザーは、内部ネットワーク上のホストにアクセスする前に、まずファイアウォールシステムにログインしなければなりません。

ファイアウォールは、一部の内部ネットワーク間でも有効です。たとえば、ファイアウォール、すなわちセキュリティー保護ゲートウェイコンピュータを設定することによって、パケットの転送を制限できます。ゲートウェイコンピュータは、ゲートウェイ自身をパケットの発信元アドレスまたは着信先アドレスとしないような、2 つのネットワーク間のパケット交換を禁止できます。また、ファイアウォールは、特定のプロトコルについてのみパケットを転送するように設定する必要があります。たとえば、パケットでメールを転送できるが、telnet や rlogin コマンドのパケットは転送できないようにできます。ASET は、高度なセキュリティーを適用して実行すると、インターネットプロトコル (IP) パケットの転送機能を無効にします。

さらに、内部ネットワークから送信されるすべての電子メールは、まずファイアウォールシステムに送信されます。ファイアウォールは、このメールを外部ネットワーク上のホストに転送します。ファイアウォールシステムは、すべての着信電子メールを受信して内部ネットワーク上のホストに配信するという役割も果たします。

ファイアウォールは、アクセス権のないユーザーが内部ネットワーク上のホストにアクセスする行為を防止します。ファイアウォールに適用される厳密で確実なセキュリティーを管理する必要がありますが、ネットワーク上の他のホストのセキュリティーはもっと緩やかでも構いません。ただし、ファイアウォールシステムを突破できる侵入者は、内部ネットワーク上の他のすべてのホストへのアクセスを取得できる可能性があります。

ファイアウォールシステムには、信頼されるホストを配置しないでください。「信頼されるホスト」とは、ユーザーがログインするときに、パスワードを入力する必要がないホストのことです。ファイアウォールシステムでは、ファイルシステムを共有しないでください。また、ほかのサーバーのファイルシステムをマウントしないでください。

次の技術は、システムを強化してファイアウォールを確立するのに利用できます。

• ASET は、ファイアウォールシステムにおける高セキュリティーを実現します。詳細は、第 7 章自動セキュリティー拡張ツールの使用 (手順)を参照してください。

• Sun Security Toolkit (旧名称: JASS ツールキット) は、Solaris システムを強化してファイアウォールを確立するために利用できます。このツールキットは、Sun の Web サイト http://www.sun.com/software/security/jass からダウンロードできます。

• IPsec と Solaris IP フィルタには、ファイアウォール保護機能があります。ネットワークトラフィックの保護についての詳細は、『Solaris のシステム管理 (IP サービス)』のパート IV「IP セキュリティー」を参照してください。

暗号化システムとファイアウォールシステム

ほとんどのローカルエリアネットワークでは、データは「パケット」と呼ばれるブロック単位でコンピュータ間で転送されます。ネットワークの外部にいるアクセス権のないユーザーが、「パケットスマッシング」という方法により、データを変更または破壊する可能性があります。

パケットスマッシングでは、パケットが宛先に到達する前に取り込まれます。侵入者は、その内容に勝手なデータを書き込み、パケットを元のコースに戻します。ローカルエリアネットワーク上では、パケットはサーバーを含むすべてのシステムに同時に到達するので、パケットスマッシングは不可能です。ただし、ゲートウェイ上ではパケットスマッシングが可能なため、ネットワーク上のすべてのゲートウェイを保護する必要があります。

もっとも危険なのは、データの完全性に影響するような攻撃です。このような攻撃を受けると、パケットの内容が変更されたり、ユーザーが偽装されたりします。盗聴を伴う攻撃では、データの完全性が損なわれることはありません。盗聴者は、会話を記録して、あとで再生します。盗聴者がユーザーを偽装することはありません。盗聴攻撃によってデータの完全性が損なわれることはありませんが、プライバシが侵害されます。ネットワーク上でやりとりされるデータを暗号化すると、重要な情報のプライバシを保護できます。

• セキュリティー保護されていないネットワーク上での遠隔処理を暗号化する方法については、第 19 章Solaris Secure Shell の使用 (手順)を参照してください。

• ネットワーク上でのデータの暗号化と認証を行う方法については、第 21 章Kerberos サービスについてを参照してください。

• IP データグラムを暗号化する方法については、『Solaris のシステム管理 (IP サービス)』の第 19 章「IP セキュリティーアーキテクチャー (概要)」を参照してください。

セキュリティー問題の報告

セキュリティーの問題が発生した可能性がある場合は、Computer Emergency Response Team/Coordination Center (CERT/CC) に連絡してください。CERT/CC は、Defense Advanced Research Projects Agency (DARPA) の資金提供を受けたプロジェクトで、カーネギメロン大学の Software Engineering Institute にあります。CERT/CC はセキュリティー問題の解決を支援できます。また、特定のニーズに合った他の Computer Emergency Response Team を紹介することもできます。CERT/CC に連絡するには、24 時間のホットラインに電話する方法と、電子メールをcert@cert.sei.cmu.edu に送る方法があります。