2


システムのセキュリティーの確保 : 手法の適用

この章では、システムのセキュリティーを確保するための方法について説明します。Solaris Security Toolkit を使用してシステムのセキュリティーを確保する場合は、あらかじめこのソフトウェアのプロセスを適用できます。

この章では、以下の項目を説明します。


計画と準備

Solaris Security Toolkit ソフトウェアを使用してシステムのセキュリティーを確保するには、適切な計画が不可欠です。計画段階では、組織のセキュリティーポリシーと基準、システムのアプリケーションと動作条件に基づいて、Solaris Security Toolkit プロファイルを開発します。この段階では以下の作業を実行します。

このマニュアルでは触れていませんが、このほかにも、リスクとセキュリティー問題の把握、インフラストラクチャーとそのセキュリティー要件の把握、アカウンタビリティー、ログ、および使用状況監査の検討なども計画段階に含まれる作業です。

リスクと利益の検討

システムを強化する際は、Solaris Security Toolkit ソフトウェアを実行後にシステムが正常に動作するように、特別な注意が必要です。また、システムの停止時間を最短に抑えるため、プロセスを最適化することが重要です。



注 - 配備済みのシステムでセキュリティー確保を実行する場合は、システムを再構築し、インストール時にセキュリティーを強化してから、システムの動作に必要なすべてのソフトウェアを再度読み込む方が効果的なことがあります。



この節では、システムのセキュリティー確保を行う前に明確に把握しておくべき事柄について説明します。リスクと利益を比較検討し、組織にとって適切なアクションを決定してください。

1. システムのサービスおよびアプリケーションの条件を把握します。

Solaris Security Toolkit ソフトウェアを実行する前に、システムで実行されているサービスおよびアプリケーションを識別する必要があります。Solaris Security Toolkit ソフトウェアを正しく構成するために、サービスおよびアプリケーションの依存関係をすべて列挙してください。この作業を行わないと、サービスが無効になったり、必要なサービスを起動できなくなったりする可能性があります。Solaris Security Toolkit ソフトウェアで行われた変更は、ほとんどの場合、元に戻すことができます。しかし、インストール前に正しいプロファイルを開発しておくことで、ソフトウェアの実行に関連する潜在的なシテスム停止時間を制限できます。

2. システムをオフラインにして再起動する必要があることを考慮します。

Solaris Security Toolkit ソフトウェアで行われた変更を有効にするには、システムを再起動しなければなりません。システムの重要度、システムが提供しているサービス、および保守ウィンドウの可用性によっては、ソフトウェアを実行できない場合があります。システムの停止時間とセキュリティーを強化しなかった場合のリスクとを慎重に比較検討して、決定する必要があります。

3. 機能性を検証するために、システムを数回再起動しなければならないことがあります。

可能なかぎり、システムをミッションクリティカルな設定で実装する前に、すべての変更はまず非実働システムで行います。しかし、これは常に可能であるとは限りません。ハードウェアまたはソフトウェアの不足のため、対象となる環境を有効にミラー化できない場合もあります。Solaris Security Toolkit ソフトウェアによる強化処理の前後でテストを実施する必要があります。システムを強化した後でも、障害追跡の必要な未特定の依存関係がある可能性があります。この問題は、ほとんどの場合、この章で説明する方法で簡単に解決されます。Solaris Security Toolkit ソフトウェアの実行後に機能性の問題が検出された場合、Solaris Security Toolkit ソフトウェアの効果を元に戻すか、またはシステムのセキュリティー構成をさらに変更して失われた機能を有効にするために、システムを数回再起動しなければならないことがあります。

4. プラットフォームのセキュリティー対策は、単に強化または監査だけではありません。

セキュリティーを強化するためにシステム構成の変更を検討するときは、セキュリティーの強化または監査が、システム、サービス、およびデータを保護するための対策の一部にすぎないことを認識しておくことが重要です。ほかに講じるべき対策および手段はこのマニュアルの対象範囲外ですが、アカウント管理、特権管理、ファイルシステムとデータの完全性、ホストベースのアクセス制御、侵入の検出、脆弱性のスキャンと分析、アプリケーションのセキュリティーに関連した問題なども考慮する必要があります。

5. システムは、すでに悪用可能な脆弱性を持っているか、あるいは悪用されている可能性があります。

強化対象のプラットフォームが、すでに攻撃者によって脆弱性を悪用されている可能性があります。Solaris Security Toolkit ソフトウェアでは、すでに悪用されている脆弱性を保護することはできません。脆弱性が悪用されている場合には、次の処理を行なってください。

a. システムを再インストールします。

b. Solaris Security Toolkit ソフトウェアをインストールします。

c. Solaris Security Toolkit ソフトウェアを使用してセキュリティーを強化します。

セキュリティーポリシー、基準、および関連ドキュメントの確認

システムのセキュリティー確保を行うにあたっては、プラットフォームのセキュリティーに関する組織のセキュリティーポリシー、基準、およびガイドラインを最初に把握しておくことが必要です。こうしたドキュメントには、組織内のすべてのシステムが準拠すべき要件および実践方法が記載されているため、Solaris Security Toolkit のプロファイルの土台となります。組織にドキュメントがない場合は、自分で作成することにより、Solaris Security Toolkit ソフトウェアをカスタマイズする能力を向上させることができます。



注 - これらのドキュメントを探すときは、ベストプラクティスまたはその他のドキュメントにリストされている可能性があることに留意してください。



セキュリティーポリシーについての詳細は、Sun BluePrints OnLine 掲載記事『Developing a Security Policy』を参照してください。この文書は、キュリティーポリシーが組織のセキュリティー計画で果たす役割を十分に理解するのに利用できます。

ポリシーステートメントは Solaris Security Toolkit のプロファイルの構成方法に直接影響します。以下に 2 つの例を示します。

例 1



注 - Kerberos などの拡張機能を使用すれば、Telnet と FTP は強力な認証と暗号化をサポートするように構成できます。しかし、それらのデフォルト構成は、追加されたセキュリティーレベルをサポートしません。



例 2

ポリシー - すべてのユーザーはパスワードを 30 日ごとに変更しなければならない。

プロファイルが受ける影響 - Solaris Security Toolkit ソフトウェアがパスワードの有効期限を指定するように構成できます。Solaris Security Toolkit ソフトウェアの secure.driver は、パスワードの有効期限を最大 8 週間 (56 日間) に設定します。ポリシーに適合するように、Solaris Security Toolkit ソフトウェアのプロファイルを変更する必要があります。『Solaris Security Toolkit 4.2 リファレンスマニュアル』を参照してください。

Solaris Security Toolkit ソフトウェアの secure.driver をシステム上で実行すると、パスワードの有効期限が有効になります。ただし、既存のユーザーについては、ユーザーがパスワードを変更するまではこの有効化が既存のユーザーに影響することはありません。既存のユーザーに対してパスワードの有効期限を有効にするには、各ユーザーアカウントで passwd(1) コマンドを呼び出します。既存ユーザーのパスワードを強制的に変更するには、passwd -f コマンドを使用できます。passwd(1) コマンドの詳細は、Solaris 10 OS Reference Collection を参照してください。

アプリケーションおよびサービス要件の決定

この作業を行うと、システムを強化した後でもサービスが正常に動作します。この作業は以下の手順で行います。

アプリケーションおよびサービスインベントリの識別

アプリケーション、サービス、操作または管理機能のインベントリを作成します。インベントリの作成は、システムで実際に使用されているソフトウェアを調べるために必要です。システムには多くの場合、使用されないソフトウェアや、ビジネス機能をサポートしていないソフトウェアが含まれています。

システムの構成は最小限にする必要があります。つまり、ビジネス機能のサポートに不要なソフトウェアはインストールしないようにします。システム上に不要なソフトウェアがあれば、それだけ攻撃者がシステムを悪用する機会が多くなります。また、システム上のソフトウェア数が多ければ、適用しなければならないパッチ数が増えることを意味します。Solaris OS の最小化についての詳細は、Sun BluePrints OnLine の掲載記事『Minimizing the Solaris Operating Environment for Security』を参照してください。Sun Fire システムドメインの最小化についての詳細は、Sun BluePrints OnLine 掲載文書『Part I: Minimizing Domains for Sun Fire V1280, 6800, 12K, and 15K Systems』と『Part II: Minimizing Domains for Sun Fire V1280, 6800, 12K, and 15K Systems』を参照してください。

ソフトウェアのインベントリを作成するときは、システムに常駐しているアプリケーションの他に、管理、監視、およびバックアップソフトウェアなどの基幹コンポーネントも含めてください。

サービス要件の決定

アプリケーションとサービスのインベントリを作成したら、セキュリティーの強化によって影響されるコンポーネントの依存関係があるかどうかを調べます。第三者のアプリケーションの多くは、Solaris OS で提供されるサービスを直接には使用しません。Solaris OS で提供されるサービスを直接使用するアプリケーションについては、以下の節を参照してください。



注 - この節に挙げている例はすべて、Solaris 9 OS のものです。



共有ライブラリ

アプリケーションをサポートするために必要なライブラリを把握しなければなりません。この情報は環境をデバッグする際に最も役立ちますが、システムを強化する際の準備段階でも必要です。システムの状態が不明な場合は、できるだけ多くの情報を収集して、ソフトウェアの依存関係などを把握してください。

アプリケーションで使用されるライブラリを決定するには、インストールしている Solaris OS のバージョンに応じて、次の 3 つの方法を使用できます。この節では、各方法のコード例を示します。

方法 1

ファイルシステムオブジェクトについての情報を取得するには、/usr/bin/ldd コマンドを使用します。

たとえば、ドメインネームシステム (DNS) サーバーソフトウェアのサポートに必要なライブラリを判断します。


コード例 2-1 ファイルシステムオブジェクトについての情報の取得

# ldd /usr/sbin/in.named
libresolv.so.2 => /usr/lib/libresolv.so.2
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 =>    /usr/lib/libnsl.so.1
libc.so.1 =>      /usr/lib/libc.so.1
libdl.so.1 =>    /usr/lib/libdl.so.1
libmp.so.2 =>    /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

 

方法 2

実行中のプロセスから情報を取得するには、/usr/proc/bin/pldd コマンド (Solaris OS バージョン 8、9、および 10 で利用可能) を使用します。


コード例 2-2 実行中のプロセスからの情報の取得

# pldd 20307
20307:  /usr/sbin/in.named
/usr/lib/libresolv.so.2
/usr/lib/libsocket.so.1
/usr/lib/libnsl.so.1
/usr/lib/libc.so.1
/usr/lib/libdl.so.1
/usr/lib/libmp.so.2
/usr/platform/sun4u/lib/libc_psr.so.1
/usr/lib/dns/dnssafe.so.1
/usr/lib/dns/cylink.so.1

 

方法 3

pldd コマンドは、アプリケーションによって動的に読み込まれる共有ライブラリ、およびアプリケーションがリンクされている共有ライブラリを表示します。この情報は次の truss コマンドでも取得できます。



注 - 説明を簡潔にするため、次の出力は途中までしか表示していません。




コード例 2-3 動的に読み込まれるアプリケーションの識別

# truss -f -topen,open64 /usr/sbin/in.named
20357:  open("/usr/lib/libresolv.so.2", O_RDONLY)       = 3
20357:  open("/usr/lib/libsocket.so.1", O_RDONLY)       = 3
20357:  open("/usr/lib/libnsl.so.1", O_RDONLY)          = 3
20357:  open("/usr/lib/libc.so.1", O_RDONLY)            = 3
20357:  open("/usr/lib/libdl.so.1", O_RDONLY)           = 3
20357:  open("/usr/lib/libmp.so.2", O_RDONLY)           = 3
20357:  open("/usr/lib/nss_files.so.1", O_RDONLY)       = 4
20357:  open("/usr/lib/nss_files.so.1", O_RDONLY)       = 4
20357:  open("/usr/lib/dns/dnssafe.so.1", O_RDONLY)     = 4
20357:  open("/usr/lib/dns/cylink.so.1", O_RDONLY)      = 4
20357:  open("/usr/lib/dns/sparcv9/cylink.so.1", O_RDONLY) = 4

 

このバージョンの出力には、プロセス識別子、システムコール (この場合は open) とその引数、およびシステムコールの戻り値が含まれています。戻り値から、システムコールが共有ライブラリを見つけて開くことができたことを判断できます。

共有ライブラリのリストが表示されたら、次のコマンドを使用して、共有ライブラリが属している Solaris OS パッケージを決定します。


# grep "/usr/lib/dns/cylink.so.1" /var/sadm/install/contents
/usr/lib/dns/cylink.so.1 f none 0755 root bin 63532 24346 \
1018126408 SUNWcsl

 

結果の出力では、この共有ライブラリが SUNWcsl (Core、Shared Libs) パッケージに属していることが示されます。このプロセスはアプリケーションまたはサービスをサポートするために必要なパッケージの識別に役立つため、プラットフォームの最小化を実行する際に特に有用です。

構成ファイル

サービス要件は構成ファイルを通して収集することもできます。サービスを無効にするために、構成ファイルの名前が変更されたり削除されていることがあります。したがって、このプロセスは、システムの強化方法に直接的に影響します。詳細は、『Solaris Security Toolkit 4.2 リファレンスマニュアル』を参照してください。

構成ファイルが使用されているかどうかを判断するには、truss コマンドを使用します。



注 - 説明を簡潔にするため、次の出力は途中までしか表示していません。




コード例 2-4 構成ファイルが使用されているかどうかの判定

# truss -f -topen,open64 /usr/sbin/in.named 2>&1 | \grep -v "/usr/lib/.*.so.*"
20384:  open("/etc/resolv.conf", O_RDONLY)              = 3
20384:  open("/dev/conslog", O_WRONLY)                  = 3
20384:  open("/usr/share/lib/zoneinfo/US/Eastern", O_RDONLY) = 4
20384:  open("/var/run/syslog_door", O_RDONLY)          = 4
20384:  open("/etc/nsswitch.conf", O_RDONLY)            = 4
20384:  open("/etc/services", O_RDONLY)                 = 4
20384:  open("/etc/protocols", O_RDONLY)                = 4
20384:  open("/etc/named.conf", O_RDONLY)               = 4
20384:  open("named.ca", O_RDONLY)                      = 5
20384:  open("named.local", O_RDONLY)                   = 5
20384:  open("db.192.168.1", O_RDONLY)                  = 5
20384:  open("db.internal.net", O_RDONLY)               = 5

 

この例では、DNS サービスは /etc/named.conf などの構成ファイルを使用しています。前の例と同様に、戻り値がエラーを示す場合は、問題がある可能性があります。セキュリティー強化を実行する前後で結果を注意深く文書化することで、検証プロセス全体の効率を向上させることができます。

サービスフレームワーク

このカテゴリには、大規模で複雑なアプリケーションを構築するためのフレームワークまたはメタサービスが含まれます。このカテゴリに一般に含まれるフレームワークには、次のようなタイプがあります。

アプリケーションがこうしたサービスに依存しているかどうかは不明な場合もあります。アプリケーションの構成時に、Kerberos 領域に追加するなどの特殊な操作が必要なときは、依存関係がはっきりしています。しかし、アプリケーションの依存関係が追加の作業を必要とせず、実際の依存関係がベンダーによって文書化されていないこともあります。

RPC ポートマッパーはその例です。Solaris Security Toolkit ソフトウェアの secure.driver は、RPC ポートマッパーを無効にします。このため、このサービスに依存しているほかのサービスが予期しない動作をすることがあります。過去の経験から、例外処理に対してアプリケーションのコードがうまく記述されているかどうかによって、サービスは中断、停止、または異常終了します。アプリケーションが RPC ポートマッパーを使用しているかどうかを判断するには、rpcinfo コマンドを使用します。次に例を示します。


コード例 2-5 RPC を使用しているアプリケーションの特定

# rpcinfo -p
100000    3   tcp    111  rpcbind
100000    4   udp    111  rpcbind
100000    2   udp    111  rpcbind
100024    1   udp  32777  status
100024    1   tcp  32772  status
100133    1   udp  32777
100133    1   tcp  32772
100021    1   udp   4045  nlockmgr
100021    2   udp   4045  nlockmgr
100021    3   udp   4045  nlockmgr
100021    4   udp   4045  nlockmgr
100021    1   tcp   4045  nlockmgr

 

サービス列には、/etc/rpc ファイルまたはネーミングサービス (LDAP など) から取得した情報が表示されます。

Sun 以外の製品で多く見られるように、このファイルにサービスのエントリがない場合、サービスフィールドには何も表示されません。この場合は、他のアプリケーションで登録されているアプリケーションの識別が難しくなります。

たとえば、rusers コマンドを考えてみましょう。このコマンドは RPC ポートマッピングサービスに依存しています。RPC ポートマッパーが実行されていないと、rusers コマンドは停止したように見えます。最終的には、次のエラーメッセージでタイムアウトになります。


# rusers -a localhost
localhost: RPC: Rpcbind failure

 

この問題は、プログラムがサービスと通信できないために発生します。しかし、/etc/init.d/rpc から RPC ポートマッピングサービスを起動すると、プログラムはすぐに実行して結果を返します。

別の例として、RPC ポートマッピングサービスは実行しているが、rusers サービスを実行するよう構成されていない場合を考えてみます。この場合の応答はまったく異なり、検証は比較的容易に行えます。


コード例 2-6 rusers サービスの検証

# rusers -a localhost
localhost: RPC: Program not registered
# grep rusers /etc/rpc
rusersd         100002  rusers
# rpcinfo -p | grep rusers
<出力は生成されない>

 

rpcinfo コマンドで rusers サービスのエントリが表示されないことから、このサービスが有効になっていないと予測できます。この予測を検証するには、/etc/inet/inetd.conf のサービスエントリを探します。


# grep rusers /etc/inet/inetd.conf
# rusersd/2-3   tli     rpc/datagram_v,circuit_v     wait root
/usr/lib/netsvc/rusers/rpc.rusersd     rpc.rusersd

 

サービス行の先頭にあるコメント記号 (#) は、rusers サービスが無効になっていることを示します。このサービスを有効にするには、以下のとおり、行のコメントを解除し、SIGHUP 信号を /usr/sbin/inetd プロセスに送信します。


# pkill -HUP inetd

 

注 - pkill コマンドは Solaris OS バージョン 7 〜 10 でのみ利用できます。他のバージョンの場合、ps コマンドと kill コマンドで、それぞれ、プロセスを見つけて信号を送信します。



アプリケーションが RPC 機能を使用しているかどうかを判断するには、前述の ldd コマンドを使用する方法もあります。


コード例 2-7 RPC を使用しているアプリケーションを特定する別の方法

# ldd /usr/lib/netsvc/rusers/rpc.rusersd
libnsl.so.1 =>   /usr/lib/libnsl.so.1
librpcsvc.so.1 =>        /usr/lib/librpcsvc.so.1
libc.so.1 =>     /usr/lib/libc.so.1
libdl.so.1 =>    /usr/lib/libdl.so.1
libmp.so.2 =>    /usr/lib/libmp.so.2
/usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1

 

librpcsvc.so.1 のエントリは、ファイル名とともに、このサービスが RPC ポートマッピングサービスに依存していることを示します。

RPC ポートマッパーのほかに、FTP、SNMP、NFS (Network File System) などの一般的な OS サービスにアプリケーションが依存している場合もあります。同様の方法でこれらのサービスをデバッグし、ビジネス機能をサポートするのにこれらのサービスが実際に必要かどうかを判断することができます。たとえば、netstat コマンドを以下のとおり実行します。


# netstat -a | egrep "ESTABLISHED|TIME_WAIT"

 

このコマンドは、現在使用されているサービス、または最近使用されたサービスのリストを返します。以下に例を示します。


表 2-1 最近使用されたサービスの表示

localhost.32827      localhost.32828      49152      0 49152      0 ESTABLISHED
localhost.35044      localhost.32784      49152      0 49152      0 ESTABLISHED
localhost.32784      localhost.35044      49152      0 49152      0 ESTABLISHED
localhost.35047      localhost.35046      49152      0 49152      0 ESTABLISHED
localhost.35046      localhost.35047      49152      0 49152      0 ESTABLISHED
filefly.ssh 192.168.0.3.2969     17615      1 50320      0 ESTABLISHED

 

この例では、多くのサービスが使用されていますが、どのポートがどのサービスまたはアプリケーションによって所有されているかは不明です。この情報を取得するには、pfiles(1) コマンド (Solaris OS バージョン 8、9、10 で利用可能) を使用します。pfiles コマンドは、各プロセスで開かれているすべてのファイルの情報を表示します。


コード例 2-8 サービスまたはアプリケーションによって所有されているポートの特定

# for pid in `ps -aeo pid | grep -v PID`; do
> pfiles ${pid} | egrep "^${pid}:|sockname:"
> done

 

lsof (list open file) コマンドを使用すると、依存関係をより効果的かつ効率的に判断することができます。

lsof ソースコードは、次のサイトからダウンロードしてください。

ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/

lsof バイナリは、次のサイトからダウンロードしてください。

http://www.sunfreeware.com

lsof コマンドは、どのプロセスがどのファイルおよびポートを使用しているかを調べます。たとえば、前の例のポート 35047 を使用しているプロセスを特定するには、以下のコマンドを使用します。


コード例 2-9 ファイルおよびポートを使用しているプロセスの特定

# ./lsof -i | grep 35047
ttsession   600 root 9u  IPv4 0x3000b4d47e8     0t1  TCP
localhost:35047->localhost:35046 (ESTABLISHED)
dtexec     5614 root 9u  IPv4 0x3000b4d59e8     0t0  TCP
localhost:35046->localhost:35047 (ESTABLISHED)

 

lsof の出力は、ポート 35047dtexec プロセスと ttsession プロセスとの通信に使用されていることを示します。

lsof プログラムにより、ファイルシステムまたはネットワークの使用を必要とするシステム間またはアプリケーシヨン間の依存関係を高速で調べることができる場合があります。この節で説明する情報のほとんどは、lsof プログラムの各オプションを使用して取得することができます。



注 - ここで説明した方法では、めったに使用されないサービスの依存関係は見つからないことがあります。これらの方法に加えて、Sun のドキュメントとベンダー提供のドキュメントを参照してください。




Solaris Security Toolkit プロファイルの開発および実装

計画および準備段階が終了したら、セキュリティープロファイルを開発して実装します。セキュリティープロファイルは、サイト固有のセキュリティーポリシーを実装するための、関連する構成ドライバ、強化ドライバ、およびセキュアドライバから構成されます。これには、name-{config|hardening|secure}.driver、スクリプト、ファイルなどがあります。

Solaris Security Toolkit ソフトウェアに用意されているセキュリティープロファイルのいずれかをカスタマイズするか、または独自のセキュリティープロファイルを開発します。組織のポリシー、基準、アプリケーション要件は、たとえわずかでも各組織で異なります。

セキュリティープロファイルをカスタマイズするには、終了スクリプト、監査スクリプト、環境変数、フレームワーク、およびファイルテンプレートを通してそのアクションを調整します。

詳細は、以下の章を参照してください。

スクリプト、フレームワーク関数、環境変数、ファイルについては、必要に応じて、『Solaris Security Toolkit 4.2 リファレンスマニュアル』のほかの章を参照してください。カスタマイズする主要な環境変数は JASS_FILESJASS_SCRIPTS の 2 つです。

多数のプラットフォームに共通する基準を設定し、かつプラットフォーム間の相違を維持するには、ネストまたは階層セキュリティープロファイルと呼ばれる方法を使用します。詳細は、『Solaris Security Toolkit 4.2 リファレンスマニュアル』を参照してください。カスタマイズしたセキュリティープロファイルを組織のポリシー、基準、および要件と比較し、変更が不適切でないか確認してください。


ソフトウェアのインストール

Solaris Security Toolkit ソフトウェアのインストール手順は、配備済みのシステムでも新しいシステムでも同じです。インストール手順についての詳細は、第 3 章を参照してください。

配備済みのシステムで、このプロセスをより簡単に短時間で行うことができる特殊な場合があります。こうした場合は、強化プロセスではなく、インストール前後の作業で対処します。

インストール前の作業の実行

配備済みシステムの強化を実行する前に、次の 2 つの重要な作業について検討し、計画します。

これらの作業は、配備済みシステムの状態を確認し、強化の前に構成の潜在的な問題を解決するのに役立ちます。

データのバックアップ

この作業は、データが誤って消去された場合に備えるために行います。問題が発生した場合、システムの構成およびデータが何らかの形でアーカイブされている必要があります。次の作業を行う必要があります。

これらの作業は、システムの構成に大幅な変更を加える前に行なってください。

システムの安定性の検証

検証作業はバックアップと同様に重要です。セキュリティーの強化などでシステムの構成を変更する前に、検証を行なってシステムが安定した作業状態であることを確認します。この検証は次の手順で行います。

定義済みのテストおよび承認プランの使用を推奨しますが、プランが常に利用できるとはかぎりません。プランを利用できない場合は、実際の使用方法に基づいてシステムをテストします。このプロセスでは、実行中の構成が、保存されている構成と実際に一致していることを確認します。

システムの起動時やアプリケーションの起動時に、エラーメッセージまたは警告が表示されないか調べます。修正できないエラーが発生した場合はログファイルに記録し、それがセキュリティーの強化中に発生する問題の潜在的な原因にならないようにします。ログファイルを確認するときは、以下のシステム、サービス、およびアプリケーションのログを表示します。

システムを再起動しても、エラーまたは警告メッセージ、あるいは未知のエラーまたは警告が表示されなければ、この作業は完了です (既知のエラーや警告はすべて文書化されている)。システムを再起動して安定した作業状態にしてください。検証プロセスにおいて実行中のシステム構成と保存されている構成との相違を発見した場合は、組織の変更管理ポリシーおよびプロセスを再評価し、原因を特定します。

インストール後の作業の実行

インストール後の作業はインストール前の作業の拡張であり、セキュリティーの強化によってシステムまたはアプリケーションに新たな障害が発生していないことを確認するために行います。主に、システムおよびアプリケーションのログファイルを表示して確認します。システムのセキュリティー強化およびそれに続く再起動後に生成されたログファイルが、セキュリティーの強化前に取得されたログファイルと同じでなければなりません。起動されたサービスが減少したためにメッセージ数が少ないことがありますが、最も重要なのは、新しいエラーまたは警告メッセージが表示されていないことです。

ログファイルの確認に加えて、機能性のテストを行います。アプリケーションが異常終了してもログエントリが生成されない場合もあります。検証についての詳細は、次の節を参照してください。


アプリケーションおよびサービスの機能性の検証

システムのセキュリティーを確保するプロセスの最後に、システムが提供するアプリケーションとサービスが正しく機能することを検証します。あわせて、セキュリティーポリシーの要件がセキュリティープロファイルで正常に実装されたことを検証します。この作業は、すべての問題が検出されて即座に修正されるように、プラットフォームの強化直後に完璧に実行します。この作業は、セキュリティープロファイルのインストールの検証と、アプリケーションおよびサービスの機能性の検証という 2 つの作業に分かれています。

セキュリティープロファイルのインストールの検証

Solaris Security Toolkit ソフトウェアがセキュリティープロファイルを正常にインストールしたことを検証するには、インストールログファイル jass-install-log.txt を確認します。このファイルは、/var/opt/SUWWjass/runs の下の各強化処理または監査処理 (処理の開始時間) 固有のディレクトリにインストールされます。



注 - Solaris Security Toolkit ソフトウェアがシステムに対して行った操作を確認するには、このログファイルを参照してください。実行のたびに、その開始時刻に基づいて、ディレクトリ内に新しいログファイルが保存されます。



プロファイルのインストールに加えて、システムのセキュリティー構成も評価します。検査は手動で行うか、またはツールを使用して自動的に行います。

アプリケーションおよびサービスの機能性の検証

アプリケーションおよびサービスを検証するには、定義済みのテストおよび承認プランを実行します。このプランは、システムまたはアプリケーションのさまざまなコンポーネントを検査して、利用可能な作業状態であることを確認します。このような計画を用意できない場合は、システムの使用方法に応じて妥当な方法でテストします。このプロセスでは、セキュリティーの強化によってアプリケーションまたはサービスの機能が影響を受けていないことを確認します。

システムのセキュリティー強化後にアプリケーションまたはサービスの誤動作を検出した場合は、アプリケーションログファイルで問題を確認します。一般的に、truss コマンドを使用してアプリケーションの問題箇所を見つけることができます。不具合な箇所がわかったら、問題を絞り込んで、Solaris Security Toolkit ソフトウェアで行われた変更を特定します。


システムのセキュリティーの維持

多くの組織に共通している誤りは、セキュリティーに対してインストール時にのみ注意を払い、以降はまったく、あるいはほとんど確認を行わないことです。セキュリティーの維持は常時実行されているプロセスであり、定期的な確認および見直しが必要です。

システムのセキュリティー構成は、時間がたつにつれて他人に知られようになるため、セキュリティーを維持するには用心しなければなりません。たとえば、システムの脆弱性などは次第に知られるようになります。

次に、システムセキュリティーの維持に関する基本的なガイドラインを示します。

Solaris OS パッチのインストールには追加のソフトウェアパッケージが含まれる場合があり、それによって既存のシステム構成が上書きされることがあります。Solaris Security Toolkit ソフトウェアはパッチを適用する場合に役立ちます。システム上で繰り返し実行できるため、パッチをインストールした後でシステムのセキュリティーを確保することができます。パッチをインストールした後で、適切なドライバを使用してソフトウェアを実行し、定義されているセキュリティーポリシーにシステム構成を一致させます。使用している Solaris Security Toolkit ソフトウェアのバージョンが、パッチで追加された新しい機能をサポートしていない可能性もあるため、さらにシステムのセキュリティーを手動で確認してください。

Solaris Security Toolkit ソフトウェアには、インストール時に使用できるデフォルトのセキュリティープロファイルが用意されています。