マシンの情報のセキュリティを保つことは、重要なシステム管理作業です。この章では、マシンセキュリティ管理の概要を説明します。
この章の内容は以下のとおりです。
サイトでは、1 台のサーバーに接続された多数のマシンを、1 つの大規模で多面的なシステムとみなすことができます。システム管理者は、この大規模なシステムのセキュリティ管理に責任があります。システム管理者は、ネットワークの外部からの侵入を防ぐ必要があります。また、ネットワーク内部のマシン上のデータの完全性を確保する必要もあります。
ファイルレベルにおいて、Solaris オペレーティング環境にはいくつかの標準セキュリティ機能が組み込まれており、ファイル、ディレクトリ、およびデバイスを保護するため使用できます。システムレベルとネットワークレベルでは、セキュリティの内容はほぼ同じです。セキュリティ防御の第一線は、システムへのアクセスを制御することです。次の方法でシステムへのアクセスを制御または監視できます。
物理的なセキュリティの管理
ログイン制御の管理
リソース使用の監視と制限
ファイルの保護
ネットワークアクセスの制御
セキュリティ問題の報告
システムへのアクセスを制御するには、コンピュータ環境の物理的なセキュリティを管理する必要があります。たとえば、マシンにログインしたままこれを放置することは不当なアクセスを招く原因になります。侵入者がオペレーティングシステムやネットワークにアクセスしないとも限らないからです。コンピュータの周辺環境やコンピュータハードウェアは、不当なアクセスから物理的に保護する必要があります。
システム管理者は、ハードウェア設定に対する不当なアクセスから SPARC マシンを物理的に保護することができます。eeprom(1M) コマンドを使って、パスワードがないと PROM にアクセスできないようにしてください。詳細は、ハードウェアアクセスのパスワードを必須にする方法を参照してください。
システムやネットワークへの無許可のログインも防止する必要があります。この制限は、パスワード制御とログイン制御によって行うことができます。システム上のすべてのアカウントには、パスワードを設定します。パスワードはシンプルな認証メカニズムです。アカウントにパスワードを設定しないと、ユーザー名を推測できる侵入者であれば誰でもネットワーク全体にアクセスできることになります。力ずくの野蛮な攻撃を許さないためには、強力なパスワードアルゴリズムが必要です。
ユーザーがシステムにログインすると、login コマンドは /etc/nsswitch.conf ファイル内の情報に従って、該当するデータベースを照会します。このファイルには次のエントリを含めることができます。
files – ローカルマシンの /etc ファイルを指定する
nis – NIS マスターサーバーの NIS データベースを指定する
nisplus – NIS+ root サーバーの NIS+ データベースを指定する
ldap – LDAP サーバーの LDAP ディレクトリサービスを指定する
nsswitch.conf ファイルの詳細は、nsswitch.conf(4) のマニュアルページを参照してください。ネームサービスまたはディレクトリサービスの詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』または『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』を参照してください。
login コマンドは、入力されたユーザー名とパスワードを確認します。ユーザー名がパスワードファイルにないと、 login コマンドはマシンへのアクセスを拒否します。あるいは、入力されたユーザー名に対するパスワードが正しくないと、login コマンドはマシンへのアクセスを拒否します。有効なユーザー名とそれに対応するパスワードが入力されれば、システムはマシンへのアクセスをユーザーに許可します。
Solaris システムには、精巧な認証メカニズムと承認メカニズムが備わっています。ネットワークレベルでの認証メカニズムや承認メカニズムについては、リモートアクセスの認証と承認を参照してください。
ユーザーはシステムにログインするときに、ユーザー名とパスワードの両方を入力する必要があります。ログイン名は公開されていますが、パスワードは秘密にしなければなりません。ユーザーは、自分のパスワードを他人に知られてはいけません。また、ユーザーが各自のパスワードを慎重に選択し、頻繁に変更するようにしなければなりません。
パスワードは、最初にユーザーアカウントを設定するときに作成されます。ユーザーアカウントのセキュリティを管理するために、パスワード有効期限を設定し、パスワードを定期的に強制変更することができます。また、ユーザーアカウントを無効にして、パスワードをロックすることもできます。パスワードの管理の詳細については、『Solaris のシステム管理 (基本編)』の「ユーザーアカウントとグループの管理 (概要)」および passwd(1) のマニュアルページを参照してください。
ネットワークで /etc 内のファイルを使用している場合、パスワード情報はシステムの /etc/passwd ファイルと /etc/shadow ファイルに保持されます。ユーザー名などの情報は、パスワードファイル /etc/passwd に保持されます。暗号化されたパスワードは、/etc/shadow という「シャドウファイル」に保持されます。このセキュリティ方式によって、暗号化されたパスワードにアクセスされることを防ぎます。/etc/passwd ファイルは、マシンにログインするユーザーであれば誰でも使用できますが、/etc/shadow ファイルを読み取ることができるのはスーパーユーザーだけです。passwd コマンドを使用すると、ローカルシステム上のユーザーのパスワードを変更できます。
ネットワークで NIS+ を使用している場合、パスワード情報は NIS+ データベースに保持されます。NIS+ データベース内の情報は、アクセス権を許可されたユーザーを制限することによって保護できます。NIS+ データベースに保持されているユーザーのパスワードを変更するには、passwd コマンドを使用します。
ネットワークで NIS を使用している場合、パスワード情報は NIS パスワードマップに保持されます。NIS では、パスワードの有効期間を指定できません。NIS パスワードマップに保持されているユーザーのパスワードを変更するには、passwd コマンドを使用します。
Solaris の LDAP ネーミングサービスは、パスワード情報とシャドウ情報を LDAP ディレクトリツリーの ou=people コンテナに格納します。Solaris LDAP ネーミングサービスクライアントでユーザーのパスワードを変更するには、passwd –r ldap コマンドを使用します。LDAP ネーミングサービスは、パスワードを LDAP リポジトリに格納します。
Solaris 9 12/02 リリースでは、SunTM Open Net Environment (Sun ONE) Directory Server 上のパスワードポリシーが適用されます。つまり、クライアントの pam_ldap モジュールは、Sun ONE Directory Server で適用されているパスワードポリシー制御に従います。詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「LDAP ネームサービスのセキュリティモデル」を参照してください。
パスワードの強力な暗号化は攻撃に対する最初の障壁になります。Solaris 9 12/02 リリースには、4 つのパスワード暗号化モジュールがあります。MD5 モジュール群と Blowfish モジュールでは、UNIX アルゴリズムよりも強固なパスワードの暗号化が行われます。
サイトのアルゴリズム構成は、/etc/security/policy.conf ファイルに指定します。policy.conf ファイルには、次の表に示す識別子でアルゴリズムを指定します。
表 15–1 パスワードの暗号化アルゴリズム
識別子 |
説明 |
アルゴリズムのマニュアルページ |
---|---|---|
1 |
BSD システムや Linux システムの MD5 アルゴリズムと互換性のある MD5 アルゴリズム |
crypt_bsdmd5(5) |
2a |
BSD システムの Blowfish アルゴリズムと互換性のある Blowfish アルゴリズム |
crypt_bsdbf(5) |
md5 |
BSD バージョンや Linux バージョンの MD5 よりも強力とされている Sun MD5 アルゴリズム |
crypt_sunmd5(5) |
__unix__ |
従来の UNIX 暗号化アルゴリズム。policy.conf ファイルのデフォルトモジュールはこのアルゴリズム |
crypt_unix(5) |
次に、デフォルトの policy.conf ファイルを示します。
# # Copyright 1999-2002 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # /etc/security/policy.conf # # security policy configuration for user attributes. see policy.conf(4) # #ident "@(#)policy.conf 1.6 02/06/07 SMI" # AUTHS_GRANTED=solaris.device.cdrw PROFS_GRANTED=Basic Solaris User # 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 # 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 かつ CRYPT_DEFAULT=1 であるとします。次の表は、パスワードの暗号化にどのアルゴリズムが使用されるかを示します。
元のパスワードアルゴリズム |
変更後のパスワードアルゴリズム |
意味 |
---|---|---|
crypt_bsdmd5 |
crypt_bsdmd5 |
crypt_bsdmd5 の識別子は 1、すなわち CRYPT_DEFAULT の値。ユーザーのパスワードは引き続き crypt_bsdmd5 アルゴリズムで暗号化される |
crypt_bsdbf |
crypt_bsdbf |
crypt_bsdbf の識別子は 2a。CRYPT_ALGORITHMS_ALLOW リストには 2a があるため、新しいパスワードは crypt_bsbdf アルゴリズムで暗号化される |
crypt_md5 |
crypt_md5 |
crypt_md5 の識別子は md5。CRYPT_ALGORITHMS_ALLOW リストには md5 があるため、新しいパスワードは crypt_md5 アルゴリズムで暗号化される |
crypt_unix |
crypt_bsdmd5 |
crypt_unix の識別子は __unix__。__unix__ 識別子は CRYPT_ALGORITHMS_ALLOW リストにないため、crypt_unix アルゴリズムを使用することはできない。新しいパスワードは CRYPT_DEFAULT アルゴリズムで暗号化される |
アルゴリズムの選択を構成するための構文については、policy.conf(4) のマニュアルページを参照してください。新しいパスワード暗号化アルゴリズムを使用する方法については、パスワード暗号化のデフォルトアルゴリズムを変更するを参照してください。
システムにアクセスする一般的な方法としては、通常のユーザーログインを使用するものと、root ログインを使用するものがあります。また、多数の特別な「システム」ログインを使用すると、ユーザーは root アカウントを使用しなくても管理コマンドを実行できます。システム管理者は、これらのログインアカウントにパスワードを割り当てます。
次の表に、システムのログインアカウントとその用途を示します。システムログインは特殊な機能を実行します。それぞれのログインに固有のグループ識別子番号 (GID) が付いています。各ログインには固有のパスワードを設定し、必要のある人だけに知らせるようにしてください。
表 15–2 システムログイン
ログインアカウント |
グループ ID |
用途 |
---|---|---|
root |
0 |
ほぼ無制限。ほかのすべてのログイン、保護、アクセス権に優先する。root アカウントはシステム全体へのアクセス権を持つ。root ログインのパスワードはきわめて厳密に保護する必要がある。root アカウントはほとんどの Solaris コマンドを所有する |
daemon |
1 |
バックグラウンド処理を制御する |
bin |
2 |
一部の Solaris コマンドを所有する |
sys |
3 |
多数のシステムファイルを所有する |
adm |
4 |
特定のシステム管理ファイルを所有する |
lp |
71 |
プリンタ用のオブジェクトデータファイルとスプールデータファイルを所有する |
uucp |
5 |
UNIX 間のコピープログラム、UUCP 用のオブジェクトデータファイルとスプールデータファイルを所有する |
nuucp |
9 |
システムにログインしてファイル転送を開始するためにリモートシステムで使用される |
侵入者にとって、リモートログインは魅力的な手段です。Solaris オペレーティング環境には、リモートログインを監視、制限、および無効にするコマンドがいくつもあります。手順については、ログインとパスワードのセキュリティを参照してください。
デフォルトでは、システムのマウスやキーボード、フレームバッファ、オーディオデバイスなど、一定のシステムデバイスを、リモートログインを通して制御したり読み取ったりすることはできません。詳細は、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/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:*: しか入っていない場合、ダイヤルアップログインは使用できません。
システム管理者は、システム活動の制御や監視を行うことができます。システム管理者は、だれがどのリソースを使用できるかを制限したり、リソースの使用状況を記録したり、だれがリソースを使用しているかを監視したりできます。 さらに、システム管理者は、リソースの不適切な使用を最小限に抑えるようにマシンを設定できます。
システムをスーパーユーザーモードにするには、root パスワードが必要です。デフォルトの構成では、ユーザーはリモートのシステムに root としてログインできません。リモートログインするとき、ユーザーは自分のユーザー名でログインしてから、su コマンドを使用して root になる必要があります。セキュリティ上の理由から、su コマンドを使用中のユーザー、特にスーパーユーザーのアクセス権を取得しようとしているユーザーを監視する必要があります。 スーパーユーザーを監視したり、スーパーユーザーの使用を制限する手順については、スーパーユーザーの監視と制限を参照してください。
役割によるアクセス制御 (RBAC) は、スーパーユーザーの権限を制限できるように設計されています。スーパーユーザーすなわち root ユーザーは、システムのすべてのリソースにアクセスできますが、RBAC を使用すれば、スーパーユーザーの権限を個別の権限からなる役割の集合に置き換えることができます。たとえば、ユーザーアカウントの作成を行う役割やシステムファイルの変更を行う役割を個別に設定できます。特定の機能または機能群を扱う役割を設定したら、root の機能からこれらの機能を取り除くことができます。
個々の役割を引き受けるためには、既存のユーザーが自分のユーザー名とパスワードを使ってログインする必要があります。ログインしたユーザーは、特別な役割パスワードを入力してその役割を引き受けます。これによって、他人が root パスワードを知ったとしても、システムに損傷を与える能力は限定されます。RBAC の詳細は、第 18 章「役割によるアクセス制御 (概要)」を参照してください。
システム管理者やユーザーによって、意図しないエラーが引き起こされるのを防止できます。たとえば、PATH 変数を正しく設定することによって、トロイの木馬の実行を防止できます。あるいは、システムのうち各人の作業に必要な部分だけをユーザーに提供することによって、ユーザーエラーを避けることができます。実際、注意深い設定を行えば、ユーザーに対して、作業を能率的に行うのに必要な部分だけを見せるようにできます。
パス変数を正しく設定しないと、他人が持ち込んだプログラムを誤って実行し、データを壊したりシステムを損傷したりするおそれがあります。このようなプログラムはセキュリティ上の危険を招くので、「トロイの木馬」と呼ばれます。たとえば、公共のディレクトリの中に別の su プログラムが置かれていると、システム管理者が気づかずに実行してしまう可能性があります。このようなスクリプトは正規の su コマンドとまったく同じに見えます。このようなスクリプトは実行後に自らを削除してしまうため、トロイの木馬が実際に実行されたという証拠はほとんど残りません。
パス変数はログイン時に自動的に設定されます。パスは、起動ファイル、すなわち .login、.profile、および .cshrc を通して設定されます。現在のディレクトリ (.) への検索パスを最後に指定すれば、このタイプのトロイの木馬を実行するのを防ぐことができます。スーパーユーザーのパス変数には、現在のディレクトリを指定しないでください。
自動セキュリティ拡張ツール (ASET) は、起動ファイルのパス変数が正しく設定されているかどうかを調べます。また、パス変数にドット (.) エントリが含まれていないか確認します。
標準シェルを使用すると、ユーザーはファイルを開く、コマンドを実行するなどの操作を行うことができます。制限付きシェルは、/usr/lib/rsh コマンドで呼び出されます。制限付きシェルを使用すると、ユーザーによるディレクトリの変更やコマンドの実行を制限できます。制限付きシェルは、リモートシェル (/usr/sbin/rsh) ではありません。標準のシェルと異なる点は次のとおりです。
ユーザーはホームディレクトリ内に限定されるため、 cd コマンドを使用してディレクトリを変更できない。したがって、システムファイルを閲覧することはできない。
ユーザーは PATH 変数を変更できないため、システム管理者によって設定された PATH のコマンドしか使用できない。さらに、完全なパス名を使ってコマンドやスクリプトを実行することもできない。
ユーザーは > または >> を使用して出力をリダイレクトできない。
制限付きシェルでは、ユーザーが使用できるシステムファイルを制限できます。このシェルは、特定のタスクを実行するユーザーのために限られた環境を作成します。ただし、制限付きシェルは完全に安全なわけではありません。このシェルの目的は、あくまでも、経験の少ないユーザーが誤ってシステムファイルを損傷するのを防止することです。
制限付きシェルについては、rsh(1M) のマニュアルページを参照してください。
制限付きシェルよりさらにセキュリティを強化したシェルが Secure Shell、すなわち ssh コマンドです。Secure Shell を使用すると、セキュリティ保護されていないネットワーク上のリモートホストに、安全にアクセスすることができます。Secure Shell 上の使用方法については、第 6 章「Secure Shell の管理 (参照)」を参照してください。
Solaris オペレーティング環境はマルチユーザー環境なので、ファイルシステムのセキュリティは、システムの最も基本的な問題です。ファイルの保護には、従来の UNIX のファイル保護と、より確実なアクセス制御リスト (ACL) との両方が使用できます。
ログイン制限を設定したあと、マシン上のデータへのアクセスを制御できます。一部のユーザーには特定のファイルの読み取りを許可し、別のユーザーには特定のファイルを変更または削除するアクセス権を与えることができます。誰にも見せたくないデータがある場合もあります。ファイルのアクセス権の設定方法については、第 16 章「ファイルのセキュリティの適用 (手順)」を参照してください。
実行可能ファイルがセキュリティリスクとなる場合があります。多くの実行可能プログラムは、スーパーユーザー (root) として実行しなければ適切に動作しません。このようなプログラムはユーザー ID が 0 (つまり、setuid=0) で実行されます。このようなプログラムはだれが実行したとしても root ID で実行されます。root ID で動作するプログラムは、プログラムがセキュリティを念頭に置いて作成されていない限り、セキュリティの問題をはらんでいます。
米国 Sun Microsystems, Inc. が setuid ビットを root に設定して出荷する実行可能プログラムを除き、setuid プログラムの使用を許可すべきではありません。setuid プログラムの使用を禁止できない場合は、少なくともその使用を制限すべきです。しっかりした管理を行うためには setuid プログラムの数を少なくする必要があります。
ASET セキュリティパッケージには、システムのセキュリティを制御して監視できるように、自動管理ツールが組み込まれています。システム管理者は ASET セキュリティレベルを指定します。ASET には、低、中、高という 3 つのセキュリティレベルがあります。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスは減少し、マシンセキュリティが厳しくなります。
詳細は、第 21 章「自動セキュリティ拡張ツールの使用 (手順)」を参照してください。
Solaris ソフトウェアには、リソースマネージャと呼ばれる精巧なリソース管理ツールがあります。リソースマネージャは、サービス拒否攻撃を防止する上で有効な場合があります。リソースマネージャでは、特定のプロジェクトに必要なリソースを割り当てたり、スクリプトがマシンのリソースを過度に使用するのを防止したり、プロジェクトが占有できる領域を制限したりすることができます。リソースマネージャの使用方法の説明や詳しい例については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「Solaris 9 リソースマネージャ (トピック)」を参照してください。
システム管理者は、システムの動作を監視する必要があります。次の点を含め、マシンのあらゆる側面に注意する必要があります。
通常の負荷はどの程度か
誰がシステムへのアクセス権を持っているか
各ユーザーはいつシステムにアクセスするか
システムでは通常どのようなプログラムを実行するか
このような情報を把握していれば、ツールを使用してマシンの使用状況を監査し、各ユーザーのアクティビティを監視できます。セキュリティ違反が疑われる場合は、監視作業が特に役立ちます。監査モジュールの詳細については、第 23 章「基本セキュリティモジュール (概要)」を参照してください。
Solaris オペレーティング環境はマルチユーザー環境です。マルチユーザー環境では、マシンにログインしているすべてのユーザーが、ほかのユーザーに属しているファイルを読み取ることができます。さらに、適切なアクセス権をもっているユーザーは、ほかのユーザーに属しているファイルを使用できます。表 15–3 は、ファイルシステムセキュリティのコマンドの一覧です。ファイルのセキュリティの作業手順については 第 16 章「ファイルのセキュリティの適用 (手順)」 を参照してください。
次の表は、ファイルとディレクトリの監視およびセキュリティに関するコマンドの一覧です。
表 15–3 ファイルシステムセキュリティのコマンド
コマンド |
説明 |
マニュアルページ |
---|---|---|
ディレクトリ内のファイルとファイル情報を表示する |
ls(1) |
|
ファイルの所有権を変更する |
chown(1) |
|
ファイルのグループ所有権を変更する |
chgrp(1) |
|
ファイルのアクセス権を変更する。記号モード (文字と記号) または絶対モード (8 進数) を使用して、ファイルのアクセス権を変更できる |
chmod(1) |
ほかのユーザーがアクセスできないようにすることによって、ファイルを安全に保つことができます。たとえば、アクセス権 600 の付いたファイルに、所有者やスーパーユーザー以外の人がアクセスすることはできません。アクセス権 700 の付いたディレクトリも同様です。ただし、ほかのだれかがユーザーパスワードや root パスワードを推測して発見すると、そのファイルにアクセスできます。さらに、アクセス不能なはずのファイルも、マシンファイルのバックアップをテープにとるたびに、バックアップテープ上に保存されます。
米国では、Solaris ソフトウェアのすべてのユーザーは、もう 1 つのセキュリティ層として暗号化キットを使用できます。この暗号化キットには crypt コマンドが組み込まれており、テキストを変換してデータを暗号化します。詳細は、crypt(1) のマニュアルページを参照してください。
ACL (「アクル」と読む) では、ファイルアクセス権の制御をより強化できます。ACL は、Solaris オペレーティング環境の従来の UNIX ファイル保護機能では不十分な場合に追加で使用します。従来の UNIX ファイル保護機能は、所有者、グループ、その他のユーザーという 3 つのユーザークラスに読み取り権、書き込み権、実行権を提供します。 ACL では、ファイルセキュリティを管理するレベルがさらに詳細になります。ACL では、次のファイルアクセス権を定義できます。
所有者のファイルアクセス権
所有者のグループのファイルアクセス権
所有者のグループに属していないユーザーのファイルアクセス権
特定ユーザーのファイルアクセス権
特定グループのファイルアクセス権
以上のカテゴリそれぞれのデフォルトアクセス権
ACL を設定する手順については、アクセス制御リスト (ACL) の使用を参照してください。
次の表に、ファイルやディレクトリに対して ACL を管理するコマンドを示します。
表 15–4 アクセス制御リスト (ACL) コマンド
コマンド |
説明 |
マニュアルページ |
---|---|---|
setfacl |
ACL エントリの設定、追加、変更、および削除を行う |
setfacl(1) |
getfacl |
ACL エントリを表示する |
getfacl(1) |
ネットワークファイルサーバーは、どのファイルを共有できるかを制御できます。また、共有ファイルにアクセスできるクライアント、およびそれらのクライアントに許可するアクセス権の種類も制御します。一般に、ファイルサーバーは、すべてのクライアントまたは特定のクライアントに、読み取り権と書き込み権、または読み取り専用アクセス権を与えることができます。アクセス制御は、share コマンドで資源を利用可能にするときに指定します。
ファイルサーバー上の /etc/dfs/dfstab ファイルは、サーバーがネットワーク上のクライアントに提供するファイルシステムを、一覧表示します。ファイルシステムの共有の詳細については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「ファイルシステムの自動共有」を参照してください。
一般的にスーパーユーザーは、ネットワーク上で共有されるファイルシステムには root としてアクセスできません。NFS システムは、要求者のユーザーをユーザー ID 60001 を持つユーザー nobody に変更することによって、マウントされているファイルシステムへの root アクセスを防止します。ユーザー nobody のアクセス権は、公共ユーザーに与えられているアクセス権と同じです。つまり、ユーザー nobody のアクセス権は資格をもたないユーザーのものと同じです。たとえば、ファイルの実行権しか公共に許可していなければ、ユーザー nobody はそのファイルを実行することしかできません。
NFS サーバーは、共有ファイルシステムのスーパーユーザー特権をホスト単位で与えることができます。この特権を与えるには、share コマンドの root=hostname オプションを使用します。このオプションは慎重に使用してください。
コンピュータは通常、複数のコンピュータからなる構成の一部です。この構成を「ネットワーク」と呼びます。ネットワークでは、接続されたコンピュータの間で情報を交換できます。さらに、ネットワークに接続されたコンピュータは、ネットワーク上のほかのコンピュータにあるデータなどのリソースにアクセスできます。ネットワーキングによってコンピュータの処理能力と性能が高まります。しかし、同時に、ネットワーキングによってコンピュータのセキュリティが危険にさらされます。
たとえば、ネットワーク内では、個々のマシンは情報を共有できるように開放されています。また、多数の人々がネットワークにアクセスするので、特にユーザーエラーを通じて、不当なアクセスが発生する可能性も大きくなります。たとえば、パスワードの不適切な扱いも不当なアクセスの原因になりえます。
一般にネットワークのセキュリティは、リモートシステムからの操作を制限またはブロックすることを指しています。次の図は、リモート操作に適用できるセキュリティ制限を示します。
「認証」とは、リモートマシンにアクセスできるユーザーを特定のユーザーに限定する方法です。認証は、マシンレベルでもネットワークレベルでも設定できます。いったんユーザーがリモートマシンにアクセスすると、「承認」という方法でそのユーザーがリモートシステム上で実行できる操作が制限されます。次の表に、ネットワーク上のマシンを許可されていない使い方から保護できる、認証と承認の種類を示します。
表 15–5 リモートアクセスの認証と承認の種類
形式 |
説明 |
参照先 |
---|---|---|
LDAP と NIS+ |
LDAP ディレクトリサービスと NIS+ ネームサービスは、ネットワークレベルで認証および承認を行う |
『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』および『Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)』 |
リモートログインコマンド |
リモートログインコマンドを使用すると、ユーザーはネットワーク経由でリモートマシンにログインし、そのリソースを使用できる。リモートログインコマンドには rlogin、rcp、 ftp がある。「信頼される (trusted) ホスト」の場合、認証は自動的に処理される。それ以外の場合は、自分自身を認証するように求められる |
『Solaris のシステム管理 (資源管理とネットワークサービス)』の「リモートシステムへのアクセス (手順)」 |
Secure RPC |
Secure RPC を使用すると、リモートマシン上で要求を出したユーザーの認証が行われ、ネットワーク環境のセキュリティが高まる。Secure RPC には、UNIX、DES、または Kerberos 認証システムを使用できる | |
|
Secure RPC を使用すると、NFS 環境にセキュリティを追加できる。Secure RPC を備えた NFS 環境を Secure NFS と呼ぶ | |
DES 暗号化 |
データ暗号化規格 (DES) 暗号化機能は 56 ビットの鍵を使用して、秘密鍵を暗号化する | |
Diffie-Hellman 認証 |
この認証方法は、送信側マシンの、共通鍵を使用して現在の時刻を暗号化する機能を利用する。受信側マシンは共通鍵の復号化を行い、復号化された時刻と受信側マシンの現在の時刻とを比較する | |
Kerberos |
Kerberos は DES 暗号化を使用して、システムのログイン時にユーザーを認証する |
例については、マスター KDC を構成する方法を参照 |
Secure RPC を実行したくない場合は、代わりに Solaris の「特権付きポート」メカニズムを使用できます。特権付きポートには、1024 未満のポート番号が割り当てられます。クライアントシステムは、クライアントの資格を認証したあと、特権付きポートを使用してサーバーへの接続を設定します。次に、サーバーは接続のポート番号を検査してクライアントの資格を確認します。
ただし、Solaris 以外のクライアントは、特権付きポートを使用して通信できないことがあります。クライアントが特権付きポートを使って通信できない場合は、次のようなエラーメッセージが表示されます。
“Weak Authentication NFS request from unprivileged port” |
ファイアウォールシステムを設定すると、ネットワーク内のリソースを外部のアクセスから保護できます。「ファイアウォールシステム」は、内部ネットワークと外部ネットワークの間のバリアとして機能するセキュリティ保護ホストです。個々のネットワークはほかのネットワークを「信頼された状態でない」ものとして扱います。内部ネットワークと、インターネットなどの外部ネットワークとの間に、このような設定を必ず行うようにしてください。
ファイアウォールはゲートウェイとしても機能しますし、バリアとしても機能します。ファイアウォールは、まず、ネットワーク間でデータを渡すゲートウェイとして機能します。さらに、ファイアウォールは、データが勝手にネットワークに出入りしないようにブロックするバリアとして機能します。ファイアウォールは、内部ネットワーク上のユーザーに対して、ファイアウォールシステムにログインしてリモートネットワーク上のホストにアクセスするように要求します。また、外部ネットワーク上のユーザーは、内部ネットワーク上のホストにアクセスする前に、ファイアウォールシステムにログインしなければなりません。
ファイアウォールは、一部の内部ネットワーク間でも有効です。たとえば、ファイアウォール、すなわちセキュリティ保護ゲートウェイコンピュータを設定することによって、パケットの転送を制限できます。ゲートウェイコンピュータは、ゲートウェイ自身をパケットの発信元アドレスまたは着信先アドレスとしないような、2 つのネットワーク間のパケット交換を禁止できます。また、ファイアウォールは、特定のプロトコルについてのみパケットを転送するように設定する必要があります。たとえば、パケットでメールを転送できるが、telnet や rlogin コマンドのパケットは転送できないようにできます。ASET は、高度なセキュリティを適用して実行すると、インターネットプロトコル (IP) パケットの転送機能を無効にします。
さらに、内部ネットワークから送信されるすべての電子メールは、まずファイアウォールシステムに送信されます。ファイアウォールは、このメールを外部ネットワーク上のホストに転送します。ファイアウォールシステムは、すべての着信電子メールを受信して、内部ネットワーク上のホストに配信します。
ファイアウォールは、アクセス権のないユーザーが内部ネットワーク上のホストにアクセスする行為を防止します。ファイアウォールに適用される厳密で確実なセキュリティを管理する必要がありますが、ネットワーク上の他のホストのセキュリティはもっと緩やかでもかまいません。ただし、ファイアウォールシステムを突破できる侵入者は、内部ネットワーク上の他のすべてのホストへのアクセスを取得できる可能性があります。
ファイアウォールシステムには、信頼されるホストを配置しないでください。信頼されるホストとは、ユーザーがログインするときに、パスワードを入力する必要がないホストのことです。ファイアウォールシステムでは、ファイルシステムを共有しないでください。また、ほかのサーバーのファイルシステムをマウントしないでください。
ASET を使用すると、マシンをファイアウォールに強固に組み込むことができます。ASET によって、ファイアウォールシステムのセキュリティが高まります (第 21 章「自動セキュリティ拡張ツールの使用 (手順)」を参照)。同様に、IPsec もファイアウォールの保護が可能です。IPsec を使ってネットワークトラフィックを保護する方法については、『Solaris のシステム管理 (IP サービス)』の「IPsec (概要)」を参照してください。
ほとんどのローカルエリアネットワークでは、データはパケットと呼ばれるブロック単位でコンピュータ間で転送されます。アクセス権のないユーザーが、「パケットスマッシング」という方法により、データを損傷する可能性があります。あるいは、データを破壊する可能性もあります。パケットスマッシングでは、パケットが宛先に到達する前に取り込まれます。侵入者は、その内容に勝手なデータを書き込み、パケットを元のコースに戻します。ローカルエリアネットワーク上では、パケットはサーバーを含むすべてのマシンに同時に到達するので、パケットスマッシングは不可能です。ただし、ゲートウェイ上ではパケットスマッシングが可能なため、ネットワーク上のすべてのゲートウェイを保護する必要があります。
最も危険なのは、データの完全性に影響するような攻撃です。このような攻撃を受けると、パケットの内容が変更されたり、ユーザーが偽装されたりします。盗聴を伴う攻撃では、データの完全性が損なわれることはありません。盗聴者は、会話を記録して、あとで再生します。盗聴者がユーザーを偽装することはありません。盗聴攻撃によってデータの完全性が損なわれることはありませんが、プライバシが侵害されます。ネットワーク上でやりとりされるデータを暗号化すると、重要な情報のプライバシを保護できます。IP データグラムの暗号化方法については、『Solaris のシステム管理 (IP サービス)』の「インターネットキー交換」を参照してください。
セキュリティの問題が発生した可能性がある場合は、The 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 に送る方法があります。