この章では、Trusted Solaris ワークステーションで構成されたネットワークの監査の設定について重点的に説明します。また、ネットワークに接続されていない Trusted Solaris ワークステーションの監査の設定方法についても説明します。
システム管理者、セキュリティ管理者によって最初の Trusted Solaris 用ワークステーションが設定されると、監査が有効になり、デフォルトの監査ロケーション workstation-name:/var/audit に一定数の監査レコードが集められます。セキュリティ管理者は、監査する対象を決定し、イベントとクラスの対応関係をサイト独自の仕様にする (カスタマイズする) かどうかを計画します。システム管理者は、監査ファイルを保存するローカルディスクとリモートディスクの容量、監査管理サーバー、インストールの順番を計画します。
ネットワークに接続されていないワークステーションの監査計画は比較的簡単です。ただ、こうした単独のワークステーションでは、イベントとクラスの対応関係をカスタマイズしても、その時間に見合う効果が得られません。この場合にもっとも重要なのは、作業の効率を落とさないで監査を行うということです。監査パーティションのサイズと場所の計画を立てると、作業の効率低下を防ぐことができます。また、定期保守スケジュールを立てることで、自動的にバックアップをとったり、監査パーティションを解放して、より多くの監査レコードを収集することができます。
Trusted Solaris は、ユーザーアクションによるイベントとユーザーアクションを原因としないイベント (監査フラグ na、監査クラス non-attribute) を監査クラスに収集します。このようにして多くのイベントを備えた各監査クラスは、イベントが成功した場合、失敗した場合、またはその両方の場合に監査されます。
監査フラグとそれが示すイベントの種類を理解してから監査を実施してください。サイトに必要なセキュリティの程度と管理するユーザーのタイプに基づいて、監査の方針を立てます。
プロセス監査事前選択マスクが動的に修正されない限り、ユーザーがログインしたときに決定した監査特性は、ログインセッション中すべての子プロセスに引き継がれます。また、データベースが修正されない限り、プロセス事前選択マスクはその後のログインセッションすべてに適用されます。
提供されている監査クラスのリストについては、付録 A 「イベントとクラスの対応関係」を参照してください。リストは、監査クラス別に、各監査イベントに対応するシステムコールまたはユーザーコマンドを示し、監査レコードの書式の説明もしくは参照先を記載しています。
セキュリティ管理者は、サイトのセキュリティポリシーに基づいて監査対象イベントを決定します。システム全体に同じ監査対象を設定できるだけでなく、特定ユーザーに対しては免除したり追加することもできます。
ユーザーアクションを原因としないイベントを監査するかどうか決定します。
監査フラグ na は、ユーザーアクションを原因としないイベントクラス (non-attribute) を表します。ユーザーアクションを原因としないイベントには、PROM のアクセス、ブート、リモートマウントなどがあります。デフォルトの non-attribute クラスのイベントについては、「監査クラス na のイベント」のリストを参照してください。
クラスを監査するということは、そのクラスのイベントすべてを監査するということです。ユーザーアクションを原因としないクラスをカスタマイズしたい場合には、「イベントとクラスの対応関係の計画 - サイト独自の設定」を参照してください。
ユーザーアクションを原因としないイベントを監査するためには、audit_control ファイルの naflags: 行に na フラグを設定します。
イベントが成功した場合に監査するのか、失敗した場合に監査するのか、または成否に関わらず監査するのかを決定します。
ユーザーアクションを原因としないイベントが成功した場合に監査するには、audit_control ファイルの naflags: 行に次のように記述します。
naflags:+na
ユーザーアクションを原因としないイベントが失敗した場合に監査するには、次のように記述します。
naflags:-na
ユーザーアクションを原因としないイベントを成否に関わらず監査するには、次のように記述します。
naflags:na
すべて (all) のイベントを監査するかどうかを決定します。
クラス all には、Trusted Solaris ソフトウェアシステムの監査イベントがすべて含まれます。ただし、特別な状況でない限り、すべてのイベントを監査する必要はありません。
すべてのイベントを監査する場合以外は、監査クラス na 以外についても 手順 1 と 手順 2 を繰り返します。
最初のワークステーションで監査を設定する場合には、手順 3 、手順 4 での決定も audit_control ファイルに書き込みます。
naflags: 行に na フラグを入力したのと同じ要領で、audit_control ファイルの flags: 行にフラグを入力します。
特定のユーザーまたは役割に、システム全体の設定とは異なった監査対象を設定するかどうかを決定します。
例外を audit_user ファイルに書き込みます。
整合性を確認します。
audit_control ファイルの naflags: 行の内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。
audit_control ファイルの flags: 行の内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。
audit_user ファイルの内容は、Trusted Solaris ネットワークのすべてのワークステーションに共通です。
サイトでの監査対象は、サイトの監査ポリシーと、時間、効率、ディスク容量などの監査コストによって決まります。監査コストの説明については、「監査のコストの管理」を参照してください。Trusted Solaris 環境に実装されている監査機能を使用する際は、次の点について検討します。
監査対象ごとに監査レコードが作成されるため、すぐにディスクが占有されてしまう
最初は監査対象を少なくしておいて、監査パーティションがいっぱいになるタイミングを確認しましょう。こうすると、経験に基づいてディスクの必要量を推定したり、監査ファイルの保存の計画を立てることができます。監査トレールのサイズの見当がつけば、監査クラスを細かく設定することができます。
監査クラスに含まれるイベント数によって生成されるレコードの数が決まるわけではない
file read クラスには login or logout クラスとほぼ同数のイベントがありますが、file read クラスのイベントの成功を監査するように設定すると、login or logout クラスに同様の設定をした場合に比べて、生成されるレコードの数がかなり多くなります。
失敗したイベントの監査では異常なイベントが検出され、成功したイベントの監査ではシステムの使用状況が監視される
サイトポリシーでシステムの使用状況を監視するように定められている場合には、監査トレールに使用する容量を、異常なイベントを監査する場合より多めに確保しておくとよいでしょう。
失敗したイベントの監査では、成功したイベントの監査ほど多くのレコードが生成されない
たとえば、熟練したユーザーで構成される Trusted Solaris システムで file read イベントの失敗を監査した場合、file read クラスのイベントの成功を監査する場合に比べて、生成されるレコードの数がかなり少なくなります。
監査クラスごとに構成を変えたり、新しい監査クラスを設定すると、より効率的にサイトの要件を満たすことができる。また、サイトポリシーで特に監査するよう定められていない監査イベントを除外すると、監査トレールのサイズを小さくすることができる
たとえば、デバイス用のクラス de を作成した場合について考えましょう。デバイスを構成する際に、クラス de の成功したイベントを監査すると、構成とテストの完了したデバイスの監査レコードが得られます。すべてのデバイスが構成されたら、今度はクラス de の失敗したイベントを監査します。
一部のクラスを断続的に監査するように設定した場合でも、サイトの要件を満たすことができる
たとえば、上の例の監査クラス de を断続的に監査することもできます。cron ジョブ (auditconfig(1M) コマンド) を使って、特定のクラスの監査の有効と無効を切り替えたり、別の監査フラグを動的に設定することができます。
省略可能:この節は、クラスに割り当てるイベントの構成を変更したり、新しいクラスや新しいイベントを作成する場合にお読みください。デフォルトのイベントとクラスの対応関係を使用する場合には、省略してかまいません。
Trusted Solaris の監査クラスは、クラス all を含めて最大 32 個まで設定できます。定義済みのクラスと合わせて 32 個になるまで、サイトで新規クラスを追加できます。
セキュリティ管理者は、クラスとイベントの対応関係を設定します。この対応関係はそのサイトに固有のものです。次の手順に従ってください。
必要なクラスを決定します。
どのイベントがどのクラスに所属するかを決定します。
クラスごとにイベントの成功、失敗、成功と失敗の両方のうち、どの場合を監査するかを決定します。
新しいソフトウェアをインストールした場合など、プログラムに Trusted Solaris 7 ソフトウェアが提供するもの以外の監査イベントが含まれている場合には、そのイベントを既存のクラスに追加するか、新しいイベント用のクラスを新規に作成します。
Trusted Solaris 環境で監査クラスの内容のデフォルトを変更して新しいクラスを作成するときは、次の要素を検討します。
このマニュアルで説明しているのは、デフォルトの監査構成についてです。
サイトで監査デフォルトに加えた変更点を文書化して、監査管理を担当する管理者が使用できるようにする
システムがネットワークに接続されている場合には、1 台のワークステーションのファイルを変更したら、すべてのワークステーションの監査構成ファイルを変更する
Trusted Solaris ワークステーションのネットワークは 1 台のワークステーションのように操作でき、ネットワーク上のどのワークステーションでも、監査するクラス、監査のデフォルト、例外とするユーザー、イベントとクラスの対応関係が同じになります。
ネットワークに接続されていないワークステーションの監査レコードを保存するには、監査レコード専用のローカルパーティションを少なくとも 2 つ設定し、1 つを主パーティション、1 つをバックアップ用パーティションとして、保守スケジュールを組む必要があります。
一方、複数のワークステーションによるネットワークで監査レコードを保存するには、監査レコード専用のローカルパーティション (バックアップパーティション) と、複数の監査サーバーによるネットワーク、さらに監査管理サーバー 1 台を設定する必要があります。各監査サーバーにはリモートホストの監査レコードを保存するためのパーティション (主パーティション) がおかれています。監査サーバーからは、監査トレール全体を監視することができます。監査トレールとは、ネットワーク上の各ワークステーションで作成される監査ファイルのことです。また、監査ファイルとは、ワークステーションで生成される監査レコードを保持するためのファイルのことです。
ネットワークに接続されていないワークステーションでは、監査レコードを保持するディスクパーティションのサイズを決定します。効率化のためには、監査レコードを別々のディスクに配置するのがいちばんです。また、安全のためには、そのディスクに 2 つの監査パーティションを設定して、1 つを主な記憶領域とし、もう 1 つを最初のパーティションがいっぱいになった場合のバックアップ記憶領域とするとよいでしょう。ファイルシステムのセキュリティ属性を設定して、監査トレールがのぞき見されないように、監査ディレクトリで制御します。
監査レコードをバックアップするまでの監査量を推定します。
セキュリティ上の必要性と監査トレールの保存に使用できるディスク容量とのバランスを検討します。
ワークステーション 1 台あたりのディスク容量は約 200M バイトですが、必要なディスク容量は監査の処理量によって変わり、この値を大幅に上回ることもあります。監査トレールの保存に使用するディスク所要量を削減したい場合は、「監査のコストの管理」、 「監査の効率」を参照してください。
監査ファイルシステムがディスク残量の減少を警告するタイミングを決定します。
audit_control ファイルで、監査パーティションの minfree しきい値を規定します。これはディスクの残量の割合であり、この値に達すると、audit_warn エイリアスによって、監査管理者に、ディスク残量が少なくなったことを知らせる電子メールが送られます。デフォルトでは、ディスク残量が 20% になると警告が送信されます。minfree しきい値は変更可能です。
ネットワークに接続されたシステムには、ユーザーのワークステーションの監査ファイルを保存する監査サーバー、中央で監査結果の分析とバックアップを行う監査管理サーバーが必要です。また、各ワークステーションにローカル監査パーティションを用意する必要があります。ディレクトリとマウント先にファイルシステムのセキュリティ属性を設定し、監査トレールがのぞき見されないようにします。のワークシートを使って監査計画の内容を記録してください。別の方法で監査ネットワークの設定を記録してもかまいません。
サイトで必要な監査量を決定します。
セキュリティ上の必要性と監査トレールの保存に使用できるディスク容量とのバランスを検討します。
分散システム上のワークステーション 1 台あたりのディスク容量は約 200M バイトですが、サイトで必要なディスク容量は監査の処理量によって変わり、この値を大幅に上回ることもあります。監査専用ローカルディスクとリモートディスクを両方とも準備できる場合には、各ディスクをそれぞれ 2 つの監査パーティションに分けてもよいでしょう。サイトのセキュリティを保守しながら監査トレールの保存に使用するディスク容量を削減したい場合は、「監査のコストの管理」、 「監査の効率」を参照してください。
監査ファイルシステムがディスク残量の減少を警告するタイミングを決定します。
audit_control ファイルで監査パーティションの minfree しきい値を規定します。minfree しきい値はディスクの残量の割合であり、この値に達すると、audit_warn エイリアスによって監査管理者に、ディスク残量が少なくなったことを知らせる電子メールが送られます。デフォルトでは、ディスク残量が 20% になると、警告が送信されます。minfree しきい値は変更可能です。
システム管理者とセキュリティ管理者が共同で監査サーバー用ワークステーションのインストールを行なってから、監査クライアント用ワークステーションのインストールを行います。
ワークステーションごとにローカル監査パーティションの計画を立てます。
ローカルパーティションは、監査サーバーのパーティションがいっぱいになった場合やネットワークを利用できない場合のバックアップパーティションです。
クライアントが使用する監査サーバーと監査ファイルシステムを決定します。
監査ネットワークのレイアウトを決定します。次の図は、リモートホストの監査レコードを格納するために使用できるファイルシステム /etc/security/audit/egret[.n]/files を持った、監査サーバー egret を示します。
命名規則に従って監査ファイルシステムに名前を付けます。
図からわかるように、ワークステーションの監査ファイルシステムには、次のような命名規則があります。
/etc/security/audit/workstationname/files /etc/security/audit/workstationname.1/files /etc/security/audit/workstationname.2/files /etc/security/audit/workstationname.3/files ...
命名規則については、「監査ファイルの保存場所」を参照してください。
ワークステーションに監査計画を実施する作業は、システム管理者とセキュリティ管理者が共同で行います。システム管理者が担当するのは、ディスクと監査サーバーのネットワークの設定であり、セキュリティ管理者が担当するのは、監査対象の決定と、その情報を監査構成ファイルに書き込む作業です。監査ネットワークの設定はシステム管理者とセキュリティ管理者が共同で行います。監査ネットワークには、次のような特徴を持たせてください。
監査結果の分析担当者は、1 台のワークステーションからネットワーク内の全ワークステーションの全監査ファイルを読み取ることができる。システムオペレータはネットワーク内の全ワークステーションの全監査ファイルのバックアップをとることができる
方法:監査サーバーを作成して、そのサーバーに全監査ディレクトリをマウントします。
監査トレールがのぞき見されない
方法:適切な任意アクセス制御と必須アクセス制御によって、監査ディレクトリを保護します。ディレクトリのアクセスを監査するのもよい方法です。
Trusted Solaris システムの各ワークステーションは、マルチユーザーモードに入った直後から、監査トレールにレコードを書き込み続ける
方法:ユーザーのワークステーションを作成する前に監査サーバーを作成します。すべてのワークステーションには、インストール時に専用の監査パーティションを作成します。
すべてのワークステーションが同じ方法で監査される
方法:すべての監査構成ファイルを置く中央ロケーションを作成します。監査構成ファイルとは、audit_event、audit_class、audit_control、 audit_startup、audit_user、audit_warn の各ファイルのことです。このマニュアルでとりあげる監査ネットワークの実例では、監査構成ファイルは NIS+ マスターの /export/home/tmp ディレクトリに置かれています。テープまたはフロッピーディスクを使って、これらのファイルをすべてのワークステーションにコピーします。
エンドユーザーのワークステーションは、設定が完了した時点で、その監査レコードを監査サーバーに送ることができる
方法:エンドユーザーのワークステーションを設定する前に、監査サーバーを作成して監査レコードを受け取れるように設定しておきます。また、システム全体の監査構成ファイルを各ワークステーションへコピーする手順や、audit_control ファイルを修正して、各ワークステーションの監査結果の保存場所を設定する手順を決定します。
監査レコードの書き込みによってエンドユーザーのワークステーションの作業効率が低下しない
方法:定期的に監査トレールをアーカイブすると、監査サーバーのディスク容量を解放できます。ローカルの監査結果の保存場所を別のディスクまたはあまり使わないディスクに設けると、監査レコードがローカルで保存されていても、エンドユーザーの作業効率は低下しません。
監査を実施するためには、システム管理者は、監査管理サーバー、監査ファイルサーバー、ローカル監査パーティションを設定し、障害発生時に警告を送るユーザーを設定します。セキュリティ管理者は、 NIS+ ルートマスター上の audit_control(4) ファイルとその他の監査構成ファイルを編集して中央ディレクトリにコピーし、これをテープまたはフロッピーディスクによって配布します。監査構成ファイルは、インストールチームによって、テープから各ワークステーションにコピーされます。セキュリティ管理者は、各ワークステーションの audit_control ファイルの dir: 行を編集し、その後、システムを再起動します。
Trusted Solaris では、事前選択されているセキュリティ関連のイベントだけが記録されます。そして、監査で考慮されるのは記録されたイベントだけです。このため、システム環境の都合でセキュリティ関連のイベントを記録するような監査構成になっていない場合、監査は実行されません。つまり、管理者は、システムのセキュリティ違反も、セキュリティ違反を犯したユーザーも、検知することができません。管理者は定期的に監査トレールを分析して、セキュリティ違反が発生していないかどうかをチェックする必要があります。
作業 |
手順の参照先 |
---|---|
監査パーティションの作成 | |
監査管理サーバーの作成 | |
監査ファイルサーバーのインストール |
監査クライアントより先にインストールする |
ファイルディレクトリの作成 | |
監査パーティションのエクスポート (ネットワークシステムの場合のみ) | |
エイリアスデータベースの編集 | |
監査パーティションのマウント (ネットワークシステムの場合のみ) |
作業 |
手順の参照先 |
---|---|
最初のワークステーションで |
|
audit_control ファイルの編集 | |
| |
Solaris セキュリティ属性の設定 | |
audit_user ファイルの編集 | |
audit_startup ファイルの編集 | |
コピーして配布 (ネットワークシステムの場合のみ) | |
セキュリティ属性の設定 |
作業 |
手順の参照先 |
---|---|
最初のワークステーションで |
|
audit_event ファイルの編集
| |
audit_class ファイルの編集 | |
コピーして配布 (ネットワークのみ) |
ここからは、1 台から複数台のワークステーションの監査を有効または無効にする手順について説明します。各コマンドは、ディスクフルワークステーションで実行してください。ディスクレスクライアントでは実行できません。
タスクの監査は、特定の役割と特定のラベルに制限したコマンドとアクションが必要です。タスクを実行できる管理役割および必要なラベルについて、タスクの説明を参照してください。役割になって特権付きのシェルを開く方法については、「特権の必要なコマンドを実行する方法」 を参照してください。
ラベル admin_low
でセキュリティ管理者になって、管理用エディタでスクリプト /etc/init.d/audit を開きます。
この処置は、監査がサイトのセキュリティ要件に含まれていない場合または監査ファイルがオーバーフローした場合にのみ、セキュリティ管理者が責任を持って行ってください。
起動スクリプトをコメントにします。
... # Start the audit daemon # if [ -f /etc/security/audit_startup ] ; then # echo "starting audit daemon" # /etc/security/audit_startup # /usr/sbin/auditd & # fi ...
内容を書き込んで、ファイルを閉じます。
管理用エディタで /etc/init.d/drvconfig ファイルを開きます。
次の行をファイルの最後に追加します。
# Disable auditing # /usr/bin/adb -wk /dev/ksyms /dev/mem > /dev/null <<end audit_active/W 0 end
シャットダウン時の監査デーモンに対する不要なメッセージを表示しないようにするには、/etc/init.d/audit の中の停止スクリプトをコメントにします。
... # Stop the audit daemon # if [ -f /etc/security/audit_startup ] ; then # /usr/sbin/audit -t # fi
内容を書き込んで、ファイルを閉じます。
システムを再起動して、変更内容を有効にします。
ユーザーまたは管理役割は、ワークステーションを再起動する承認が必要です。
監査はデフォルトで有効になっています。監査を無効にした場合には、前述の手順を逆に実行して有効にすることができます。
ラベル admin_low
でセキュリティ管理者になって、 管理用エディタで、スクリプト /etc/init.d/audit を開きます。
監査起動スクリプトからコメントを解除します。
... # Start the audit daemon if [ -f /etc/security/audit_startup ] ; then echo "starting audit daemon" /etc/security/audit_startup /usr/sbin/auditd & fi ...
内容を書き込んで、ファイルを閉じます。
監査デーモンが /etc/init.d/audit の監査停止スクリプトからコメントを取り除いて、シャットダウン時に終了できるようにします。
... # Stop the audit daemon if [ -f /etc/security/audit_startup ] ; then /usr/sbin/audit -t fi
内容を書き込んで、ファイルを閉じます。
管理用エディタを使用して、スクリプト /etc/init.d/drvconfig を開きます。
Disable auditing の後ろの行をコメントにします。
# Disable auditing # # /usr/bin/adb -wk /dev/ksyms /dev/mem > /dev/null <<end # audit_active/W 0 # end
内容を書き込んで、ファイルを閉じます。
変更内容を有効にするには、トラステッドパスメニューから「シャットダウン (Shut Down)」メニュー項目を使用して再起動します。
ここでは、ワークステーションの監査を設定する手順について説明します。
インストールの際に、ディスクをフォーマットして専用の監査パーティションを作成します。
パーティションのマウント先ディレクトリの名前には、 /etc/security/audit/workstation-name(.n) (workstation-name はワークステーション名) という命名規則を適用します。
ディスクフルワークステーションにはローカル監査ディレクトリが少なくとも 1 つ必要です。このディレクトリは、監査サーバーと通信できなくなった場合に最後の手段として使用されます。
命名規則については、「監査ファイルの保存場所」を参照してください。
監査ファイルサーバーでは、パーティションの大半に監査ファイルが保持されます。egret 監査ファイルサーバーの例を次に示します。
ディスク |
スライス |
マウント先 |
サイズ |
---|---|---|---|
c0t2d0 |
s0 |
/etc/security/audit/egret |
1.0 GB |
|
s1 |
/etc/security/audit/egret.1 |
0.98 GB |
|
s2 |
ディスク全体 |
1.98 GB |
c0t2d1 |
s0 |
/etc/security/audit/egret.2 |
502 MB |
|
s1 |
/etc/security/audit/egret.3 |
500 MB |
|
s2 |
ディスク全体 |
1002 MB |
もう 1 つのディスクには egret の /(ルート) パーティションと /swap パーティションがあります。
監査管理サーバーをはじめとするディスクフルワークステーションでは、少なくとも 1 つのパーティションをローカル監査ファイル専用とする必要があります。ワークステーション willet の例を次に示します。
ディスク |
スライス |
マウント先 |
サイズ (MB) |
---|---|---|---|
c0t3d0 |
s0 |
/ |
70 |
|
s1 |
スワップ |
180 |
|
s2 |
ディスク全体 |
1002 |
|
s3 |
/usr |
350 |
|
s4 |
/etc/security/audit/willet |
202 |
|
s7 |
/export/home |
200 |
ワークステーション 1 台あたりのディスク容量は約 200M バイトですが、サイトのディスクに必要な容量は監査の処理量によって変わり、この値を大幅に上回ることもあります。
小さいパーティションを数多く作るより、大きいパーティションを少数作るほうが効果的です。
ワークステーションのインストール後、監査パーティションを格納するディスクを追加する方法については、Solaris 7 版の『Solaris のシステム管理 (第 2 巻)』を参照してください。Trusted Solaris セキュリティ属性でディスクを保護するには『Trusted Solaris 管理の手順』を参照してください。
監査を設定するコマンドの大半は、プロファイルシェルで実行されます。プロファイルシェルでコマンドを実行するには、特権が必要です。また、アプリケーションマネージャの「システム管理 (System_Admin)」フォルダや「Solstice アプリケーション (Solstice_Apps)」フォルダにあるアクションも必要です。
ワークステーションにログインします。
自分のユーザー名を入力して Return キーを押します。
だれもログインできないようにワークステーションが保護されている場合には、「ログインを有効にする (Enable Logins)」ダイアログボックスが表示されます。
ログインを有効にすることが許容されている場合は、「ログイン (Login)」の後の「はい (Yes)」ボタンをクリックします。
ログインを有効にすることが許容されていない場合は、管理者にログインを有効にしてもらいます。
パスワードを入力します。
「了解 (OK)」をクリックしてダイアログを終了します。
今日のメッセージとラベルビルダー画面が表示されます。シングルラベルシステムでは、画面にセッションラベルの説明が表示されます。マルチラベルシステムでは、ラベルビルダーでセッション認可上限を選択します。
特別な理由がなければデフォルトのままログインします。
Return キーを押すか、「了解 (OK)」ボタンをクリックしてログインします。
割り当てられている管理役割になります。
管理役割になって、タスクによって要求されたラベルのワークスペース内の背景を右クリックし、メニューから「ツール」、「端末エミュレータ」の順に選択して、ターミナルを起動します。
clist コマンドを入力します。
# clist |
プロファイルシェルの場合はコマンドのリストが表示されます。
ラベル admin_low
でシステム管理者になって、umount(1M) コマンドを実行して監査パーティションのマウントを解除します。
たとえば、監査ファイルサーバー egret では次のように入力します。
egret$ umount /etc/security/audit/egret egret$ umount /etc/security/audit/egret.1 egret$ umount /etc/security/audit/egret.2 egret$ umount /etc/security/audit/egret.3 |
コマンド tunefs -m 0 を実行して、各パーティションに予約されているファイルシステム領域 (minfree しきい値) を 0 にします。
セキュリティ管理者は、audit_control(4) ファイルに、予約ファイルシステム領域 (minfree しきい値) を設定します。
たとえば、監査ファイルサーバー egret では次のように入力します。
egret$ tunefs -m 0 /etc/security/audit/egret egret$ tunefs -m 0 /etc/security/audit/egret.1 egret$ tunefs -m 0 /etc/security/audit/egret.2 egret$ tunefs -m 0 /etc/security/audit/egret.3 |
同様に、ワークステーション willet では次のように入力します。
willet$ umount /etc/security/audit/willet willet$ tunefs -m 0 /etc/security/audit/willet |
ファイルシステムを調整することの長所と短所については、tunefs(1M) のマニュアルページを参照してください。
ラベル admin_low
でセキュリティ管理者になって、ファイルシステムのマウントが解除されている状態で、すべての監査ファイルシステムを対象に、適切なファイルのアクセス権を設定します。
たとえば、監査ファイルサーバー egret では次のように入力します。
egret$ chmod -R 750 /etc/security/audit/egret egret$ chmod -R 750 /etc/security/audit/egret.1 egret$ chmod -R 750 /etc/security/audit/egret.2 egret$ chmod -R 750 /etc/security/audit/egret.3 |
ワークステーション willet では次のように入力します。
willet$ chmod -R 750 /etc/security/audit/willet |
ラベル admin_high
でセキュリティ管理者になって、ファイルシステムのマウントが解除されている状態で、すべての監査ファイルシステムを対象に、サイトのセキュリティポリシーで定められた Trusted Solaris セキュリティ属性のデフォルトを設定します。
ラベル admin_high
でコマンドを実行するためには、admin_high
ワークスペースを作成する必要があります。「Admin_High ワークスペースを作成する方法」の手順に従ってください。
たとえば、監査ファイルサーバー egret の場合、次のコマンドをその監査パーティションすべてで繰り返してください。
egret$ setfsattr -l "admin_high;admin_high" -s "[admin_high]" ¥ /etc/security/audit/egret |
ワークステーション willet では次のように入力します。
willet$ setfsattr -l "admin_high;admin_high" -s "[admin_high]" ¥ /etc/security/audit/willet |
-l オプションを付けると、ファイルシステムで作成されるすべてのファイルのラベルが admin_high
になります。また、-s オプションでは、監査ファイルにパーティションのデフォルト機密ラベルが設定されます。詳細については、setfsattr(1M) のマニュアルページを参照してください。
このとき、ローカル監査ファイルシステムは、ホストの /etc/vfstab ファイルにあります。
ラベル admin_high
でシステム管理者になって、ローカル監査ファイルシステムを再びマウントします。
これについては、「Admin_High ワークスペースを作成する方法」の手順に従って admin_high
プロセスを獲得します。
たとえば、監査ファイルサーバー egret では次のように入力します。
egret$ mount /etc/security/audit/egret egret$ mount /etc/security/audit/egret.1 egret$ mount /etc/security/audit/egret.2 egret$ mount /etc/security/audit/egret.3 |
同様に、ワークステーション willet では次のように入力します。
willet$ mount /etc/security/audit/willet |
マウントした各監査パーティションの最上位に files という名前のディレクトリを作成します。
たとえば、監査ファイルサーバー egret では次のように入力します。
egret$ mkdir /etc/security/audit/egret/files egret$ mkdir /etc/security/audit/egret.1/files egret$ mkdir /etc/security/audit/egret.2/files egret$ mkdir /etc/security/audit/egret.3/files |
ワークステーション willet では次のように入力します。
willet$ mkdir /etc/security/audit/willet/files |
ラベル admin_low
でシステム管理者になって、ローカルホストの dfstab(4) ファイルにローカル監査ファイルシステムをすべて入力します。
アプリケーションマネージャをクリックして「システム管理 (System_Admin)」フォルダをダブルクリックし、さらに「ファイルシステムの共有 (Share Filesystems)」アクションをダブルクリックします。
dfstab ファイルに各ローカル監査ディレクトリを入力して保護します。
たとえば、監査ファイルサーバー egret の場合、次のように記述します。
share -F nfs -o ro -d "local audit files" /etc/security/audit/egret share -F nfs -o rw=willet:audubon -d "audit willet" /etc/security/audit/egret.1 share -F nfs -o rw=grebe:audubon -d "audit grebe" /etc/security/audit/egret.2 share -F nfs -o rw=sora:audubon -d "audit sora" /etc/security/audit/egret.3
ワークステーション willet の場合は、次のように記述します。
share -F nfs -o ro -d "local audit files" /etc/security/audit/willet
トラステッドパスメニューで「シャットダウン (Shut Down)」を選択してワークステーションを再起動します。
ラベル admin_low
でシステム管理者になって、監査管理サーバー audubon で、Trusted Solaris ネットワークの全監査ディレクトリのマウント先を作成します。
監査管理サーバー audubon の場合、次のように入力します。
audubon$ mkdir /etc/security/audit/willet audubon$ mkdir /etc/security/audit/egret audubon$ mkdir /etc/security/audit/egret.1 ... |
ラベル admin_low
でシステム管理者になって、監査管理サーバーの vfstab(4) ファイルにネットワーク上の全監査パーティションを入力します。
読み取り/書き込み (rw) オプションを付けて監査ディレクトリをマウントします。リモートパーティションをマウントするためには、soft オプションを付けます。
アプリケーションマネージャをクリックして「システム管理 (System_Admin)」フォルダをダブルクリックし、さらに「マウント・ポイントの設定 (Set Mount Points)」アクションをダブルクリックします。
vfstab(4) ファイルにマウント先を入力します。
監査管理サーバー audubon の vfstab ファイルの一部は次のようになります。
egret:/etc/security/audit/egret - /etc/security/audit/egret nfs - yes bg,soft,nopriv egret:/etc/security/audit/egret.1 - /etc/security/audit/egret.1 nfs - yes bg,soft,nopriv egret:/etc/security/audit/egret.2 - /etc/security/audit/egret.2 nfs - yes bg,soft,nopriv egret:/etc/security/audit/egret.3 - /etc/security/audit/egret.3 nfs - yes bg,soft,nopriv willet:/etc/security/audit/willet - /etc/security/audit/willet nfs - yes bg,soft,nopriv ...
リモート監査ファイルサーバーのパーティションのマウント先をワークステーションごとに作成し、vfstab(4) ファイルに入力します。ラベル admin_low
でシステム管理者になって、これを行ってください。
ワークステーション willet にマウント先を作成する場合、次のように入力します。
willet$ mkdir /etc/security/audit/egret willet$ mkdir /etc/security/audit/audubon.2 |
アプリケーションマネージャをクリックして「システム管理 (System_Admin)」フォルダをダブルクリックし、さらに「マウント・ポイントの設定 (Set Mount Points)」アクションをダブルクリックします。
vfstab(4) ファイルにマウント先を入力します。
willet の vfstab ファイルの一部は次のようになります。
egret:/etc/security/audit/egret - /etc/security/audit/egret nfs - yes bg,soft,nopriv audubon:/etc/security/audit/audubon.2 - /etc/security/audit/audubon.2 nfs - yes nopriv
ラベル admin_low
でセキュリティ管理者になって、audit_control(4) ファイルに予約する空き領域の値 (minfree しきい値)を入力します。
minfree: 行に 10 から 20 までの数値を入力します。
dir:/var/audit flags: minfree:20 naflags:
内容を保存してエディタを終了します。
ラベル admin_low
でセキュリティ管理者になって、audit_control ファイルに監査ファイルの保存場所を入力します。
最初にインストールしたワークステーションで、そのローカル監査ファイルシステムを dir: 行に入力します。
NIS+ ルートマスター grebe の audit_control ファイルは次のようになります。
dir:/etc/security/audit/grebe/files flags: minfree:20 naflags:
監査ファイルサーバーのインストールと設定がすでに完了している場合は、dir: のエントリに、マウント済みファイルシステム名とその最上位のディレクトリ files を追加します。
マウント済みファイルシステムは、ワークステーションのローカルファイルシステムの前に入力します。
dir:/etc/security/audit/egret/files dir:/etc/security/audit/egret.1/files dir:/etc/security/audit/grebe/files flags: minfree:20 naflags:
内容を保存してエディタを終了します。
セキュリティ管理者になって、admin_high
プロファイルシェルで audit -s コマンドを実行します。すると、監査デーモンにより audit_control ファイルがもう一度読み込まれ、監査レコードが指定のディレクトリに書き込まれます。
$ audit -s |
監査レコードはデフォルトで /var/audit に保存されますが、この処理によって、 audit_control ファイルに入力した最初のディレクトリに保存されるようになります。
ラベル admin_low
でセキュリティ管理者になって、audit_control(4) ファイルにシステム全体の監査フラグを入力します。
ユーザーアクションを原因としないイベントを監査する場合は、naflags: 行に na クラスを入力します。
dir:/etc/security/audit/egret/files dir:/etc/security/audit/egret.1/files dir:/etc/security/audit/grebe/files flags: minfree:20 naflags:na
ワークステーションでユーザーレベルのイベントを監査する場合は、flags: 行にその他のクラスを入力します。
dir:/etc/security/audit/egret/files dir:/etc/security/audit/egret.1/files dir:/etc/security/audit/grebe/files flags:lo,ad,-all,^-fc minfree:20 naflags:na
監査フラグの各フィールドの構文については、「audit_control ファイルの例」を参照してください。
内容を保存してエディタを終了します。
分散システムでは、audit_control ファイルの監査フラグはネットワーク上の全ワークステーションで同じにします。ファイルのマスターコピーをネットワーク上のすべてのワークステーションに配布する手順については、「監査構成ファイルをネットワーク上の各ワークステーションに配布する方法」を参照してください。
ラベル admin_low
でセキュリティ管理者になって、audit_user(4) ファイルのシステム全体の監査フラグに例外ユーザー情報 (システム全体の設定とは異なった条件で監査を行うユーザーの情報) を入力します。
アプリケーションマネージャで「システム管理 (System_Admin)」フォルダを開きます。
「ユーザー監査 (Audit Users)」アクションをダブルクリックします。
ユーザー例外値を入力し、内容を保存してエディタを終了します。
次の例では、スーパーユーザー (root) のログインとログアウト (lo) は監査されますが、スーパーユーザーによるファイル作成 (fc) は、システム全体が監査されている場合でも監査されません。jane のエントリは、audit_control ファイルに規定されたフラグのうち成功した file_read イベント以外のすべてのイベントを監査することを示しています。ヌルイベント no は監査されません。
# User Level Audit User File # # File Format # # username:always:never # root:lo:no,fc jane:all,^+fr:no
ラベル admin_low
でシステム管理者になって、Aliases データベースに監査障害の警告メールを送るエイリアス名を入力します。
監査障害をメンバーに通知する audit_warn(1M) というエイリアスを追加します。
次の audit_warn エイリアスは、監査サブシステムの調査が必要な場合にセキュリティ管理者およびシステム管理者に電子メールを送ります。
Alias: audit_warn Expansion: secadmin@grebe,admin@grebe
ラベル admin_low
でセキュリティ管理者になって、audit_startup(1M) ファイルに常時監査ポリシーを入力します。
ポリシーオプション付きの auditconfig(1M) コマンドを呼び出すスクリプトを作成します。
次の例の audit_startup(1M) スクリプトは、ACL (アクセス制御リスト) を監査レコードに追加し、ワークステーションの監査ファイルシステムがいっぱいになるとワークステーションを停止し、起動時に現在の監査ポリシーを標準出力します。
#!/bin/sh auditconfig -setpolicy +slabel,+acl auditconfig -setpolicy +ahlt auditconfig -getpolicy
内容を保存してエディタを終了します。
評価済みの構成で監査を実行する場合、cnt ポリシーを有効にすることはできません。また、ahlt ポリシー (デフォルト) を無効にすることはできません。
インストール中、ラベル admin_low
でスーパーユーザーになって、最初にインストールされたワークステーションに、サイト用にカスタマイズした監査構成ファイルのコピーを置くディレクトリを作成します。
このディレクトリには、カスタマイズした audit_control、audit_user、audit_startup、audit_warn の各ファイルを置きます。イベントとクラスの対応関係を変更している場合には、audit_event ファイルと audit_class ファイルもこのディレクトリに置きます。audit_data ファイルはここには置きません。
ネットワーク上の最初のワークステーション grebe の場合、次のようにします。
# mkdir /export/home/tmp |
修正したファイルを /etc/security ディレクトリから /export/home/tmp ディレクトリへコピーします。
# cp /etc/security/audit_control /export/home/tmp/audit_control # cp /etc/security/audit_user /export/home/tmp/audit_user # cp /etc/security/audit_startup /export/home/tmp/audit_startup # cp /etc/security/audit_event /export/home/tmp/audit_event |
テープまたはフロッピーディスク装置を割り当てます。
これについては、「デバイスの割り当てと割り当て解除の方法」の手順に従います。
tar(1) コマンドを実行して /export/home/tmp ディレクトリの内容をテープまたはフロッピーディスクへコピーします。
テープまたはフロッピーディスク装置の割り当てを解除し、指示に従います。
これについては、「デバイスの割り当てを解除する方法」の手順に従います。
ラベル admin_low
でスーパーユーザーになって、新しいワークステーションを構成するごとに、テープまたはフロッピーディスクから新しいワークステーションの正しいディレクトリへファイルをコピーします。
新しいファイルのディレクトリを用意します。
# cd /etc/security # mv audit_control audit_control.orig # mv audit_startup audit_startup.orig # mv audit_warn audit_user.orig # mv audit_event audit_event.orig |
ラベル admin_low で適切なデバイスを割り当てます。
ここで、「デバイスの割り当てと割り当て解除の方法」の手順に従います。
デバイスの割り当てを解除します。
ここで、「デバイスの割り当てを解除する方法」の手順に従います。
ラベル admin_low
でセキュリティ管理者になって、リモート監査ファイルシステムのあるワークステーション、ローカル監査ファイルシステムのあるワークステーションで、それぞれの audit_control ファイルを修正します。
デバイスの割り当てと割り当て解除は、デバイス割り当てマネージャで行います。
要求された役割とラベルを指定したワークスペース内で、フロントパネルのスタイルマネージャアイコンの上にある三角形をマウスの左ボタンでクリックします。
「ツール (Tools)」サブパネルが表示されます。
デバイス割り当てマネージャアイコンを 1 回クリックします。
割り当てるデバイスをダブルクリックします。
mag_tape_0 では、テープデバイスが割り当てられます。floppy_0 では、フロッピーディスクが割り当てられます。
ラベルビルダーが表示されたら、「了解 (OK)」をクリックします。
読み込んだファイルは、admin_low
とラベル付けされます。
表示されるウィンドウの指示に従います。
デバイス割り当てマネージャが割り当てられているワークスペースへ移動します。
デバイスをダブルクリックして割り当てを解除します。
割り当てを解除するデバイスを一覧表示したウィンドウが現れます。
表示に従ってドライブからテープまたはフロッピーディスクを取り出し、適切なラベルを付けます。
Return キーを押してウィンドウを終了します。
左上のボタンをクリックして「閉じる (Close)」を選択し、「デバイス割り当てマネージャ (Device Manager)」ウィンドウを閉じます。
ここでは、デフォルトの監査クラスと監査イベントを修正する方法と、ファイルとフォルダに公開オブジェクトビットを設定して必要のない監査を減らす方法について説明します。
ラベル admin_low
でセキュリティ管理者になって、audit_classes ファイルに監査クラスを追加します。
「イベントとクラスの対応関係の計画 - サイト独自の設定」で計画したクラスを追加し、内容を保存してエディタを終了します。
すでに使用している 16 進数を割り当てることはできません。
ラベル admin_low
でセキュリティ管理者になって、「監査イベント (Audit Events)」アクションを開いて、イベントに新しいクラスを追加します。
イベントが複数のクラスに属する場合、コンマ (スペースは使わない) でクラスを区切ります。
内容を保存してエディタを終了します。
audit_control(4) ファイルと audit_user(4) ファイルを変更して、新しいクラスのイベントの監査を行えるようにします。
手順の詳細については、「監査フラグを設定する方法」や 「例外ユーザー情報を設定する方法」を参照してください。
分散システムでは、audit_class、audit_event、audit_startup、 audit_user の各ファイルはネットワーク上の全ワークステーションで 同じ内容にします。ファイルのマスターコピーをネットワーク上のすべてのワークステーションに配布する手順については、「監査構成ファイルをネットワーク上の各ワークステーションに配布する方法」を参照してください。
システムを再起動するか、セキュリティ管理者になって admin_low
プロファイルシェルで auditconfig(1M) コマンドを実行します。このとき、適切なオプションを付けます。
次の例では、監査セッション ID は 159 で、新しいクラスは gr (グラフィックアプリケーション用) と db (データベースアプリケーション用) です。
$ auditconfig -setsmask 159 gr,db |
ラベル admin_low
でセキュリティ管理者になって、audit_event(4) ファイルに監査イベントを追加します。
「イベントとクラスの対応関係の計画 - サイト独自の設定」で計画したイベントを追加し、内容を保存してエディタを終了します。
イベントが複数のクラスに属する場合、コンマでクラスを区切ります (スペースは使わない)。
他社のアプリケーション用イベント番号は 32768 から 65536 までです。詳細は、表 1-1を参照してください。
audit_control(4) ファイルと audit_user(4) ファイルを変更して、新しいクラスのイベントの監査を行えるようにします。
手順の詳細については、「監査フラグを設定する方法」や 「例外ユーザー情報を設定する方法」を参照してください。
分散システムでは、audit_class、audit_event、audit_startup、 audit_user の各ファイルはネットワーク上の全ワークステーションで 同じ内容にします。ファイルのマスターコピーをネットワーク上のすべてのワークステーションに配布する手順については、「監査構成ファイルをネットワーク上の各ワークステーションに配布する方法」を参照してください。
システムを再起動するか、セキュリティ管理者になって admin_low プロファイルシェルで auditconfig(1M) コマンドを実行します。このとき、適切なオプションを付けます。
次の例では、監査セッション ID は 159 で、新しいイベントはクラス gr (グラフィックアプリケーション用) と db (データベースアプリケーション用) にあります。
$ auditconfig -setsmask 159 gr,db |
audit_control(4) ファイルのイベントとクラスの対応関係を変更します。
ファイルを編集して、イベントごとにクラスとの対応関係を変更し、内容を保存してエディタを終了します。
イベント番号 2048 以上のイベントを変更する場合、必要な作業はこれだけです。
分散システムでは、audit_class、audit_event、audit_startup、 audit_user の各ファイルはネットワーク上の全ワークステーションで同じ内容にします。ファイルのマスターコピーをネットワーク上のすべてのワークステーションに配布する手順については、「監査構成ファイルをネットワーク上の各ワークステーションに配布する方法」を参照してください。
カーネルイベント (イベント番号 1 〜 2047) のクラスとの対応関係を修正する場合は次のようにします。
公開オブジェクトビットを設定すると、ファイルまたはディレクトリに対して成功したアクセスが監査レコードに含まれる場合、監査トレールのサイズを小さくすることができます。ファイルの公開オブジェクトビットが設定されていると、成功したアクセスの表示、一覧あるいはアクセスするファイルまたはディレクトリの属性の一覧表示が、監査レコードに書き込まれることはありません。
ラベル admin_low
でセキュリティ管理者になって、setfattrflag(1) コマンドに -p 1 オプションを付けて実行し、アクセスが公開されているファイルのローカルディレクトリに公開オブジェクトビットを設定します。
次のコマンドは、/etc ディレクトリに公開オブジェクトビットを設定します。/etc ディレクトリの検索、/etc ディレクトリのファイルの読み取り処理では、監査レコードは生成されません。
$ setfattrflag -p 1 /etc $ getfattrflag /etc Multilevel directory: no Single level directory: no Public object: yes |
ラベル admin_low
でセキュリティ管理者になって、attr_flag セキュリティ属性によって、公共アクセスが可能なファイルのマウント済みファイルシステムに公開オブジェクトビットを設定します。
たとえば、マウント済みファイルシステム /spublic の vfstab_adjunct(4) ファイルは、そのファイルシステムのすべてのファイルに公開オブジェクトフラグを設定します。
# Modified template. # /spublic; ¥ acc_acl=; ¥ mode=; ¥ attr_flag=public; ¥ gid=; ¥ uid=; ¥ slabel=; ¥ forced=; ¥ allowed=; ¥ low_range=; ¥ hi_range=; ¥ mld_prefix=mldroot; #
動的制御は、1 回につき 1 台のワークステーションに適用されます。これは、監査コマンドが適用されるのがログインした現在のワークステーションだけだからです。動的制御は、ワークステーションの監査処理のテスト (レコード量の推定など) や、ワークステーションを再起動しないで監査フラグを追加するために使用します。ただし、テスト以外の目的で 1 台のワークステーションを実行中に変更する場合には、すべてのワークステーションを変更する必要があります。
次の手続きは、監査が有効な場合に限って実行できます。
auditconfig(1M) コマンドを使うと、適切に設定された役割によって、監査ポリシーを決定し、設定可能なポリシーを調べることができます。役割がポリシーを決定するように設定されていない場合や監査機能が無効になっている場合、コマンド auditconfig -getpolicy はエラーを返します。ラベル admin_low
でセキュリティ管理者になって、実行した例です。
$ auditconfig -getpolicy audit policies = none $ auditconfig -lspolicy policy string description: arge include exec environment args in audit recs argv include exec args in audit recs cnt when no more space, drop recs and keep a count group include supplementary groups in audit recs seq include a sequence number in audit recs trail include trailer tokens in audit recs path allow multiple paths per event acl include ACL information in audit recs ahlt halt machine if we can't record an async event slabel include sensitivity labels in audit recs passwd include cleartext passwords in audit recs windata_down include downgraded information in audit recs windata_up include upgraded information in audit recs all all policies none no policies |
ファイルへの admin_high
ラベル付け、admin_high
ディレクトリへのファイル移動、監査デーモンのリセットなど、監査に変更を加えるためには、admin_high
プロセスが必要です。admin_high
プロセスは、admin_high ワークスペースで起動します。
フロントパネル上でマウスの右ボタンをクリックし、メニューから「役割になる : role 役割 (Assume secadmin Role)」(role は役割名を指します) を選択します。
secadmin (セキュリティ管理者) のワークスペースになります。
ワークスペース名 (secadmin) をマウスの右ボタンでクリックし、メニューから「ワークスペース SL を変更 (Change Workspace SL)」を選択します。
ラベルビルダーで ADMIN_HIGH ボタンをクリックします。
ラベルビルダーの下にある「了解 (OK)」をクリックします。
ワークスペースのボタンの色が黒に変わり、admin_high
ワークスペースに移動したことを示します。admin_high
ワークスペースは、管理役割でのみ使用できます。
auditconfig コマンドを使うと、監査ポリシーを変更できます。このポリシーは、監査レコードに ACL の情報を含めるかどうかなどを規定しています。ポリシー変数は動的なカーネル変数なので、設定したポリシーはワークステーションを次に起動するまで有効です。ポリシーのパラメータについては、 auditconfig(1M) のマニュアルページのリストを参照してください。
1 回のコマンド呼び出しで複数のポリシーを設定したり、既存のポリシーすべてを無効にするためには、ラベル admin_low
でセキュリティ管理者になって、ポリシーをコンマで区切ります (スペースは使わない)。
$ auditconfig -setpolicy trail,seq $ auditconfig -getpolicy audit policies = trail,seq $ auditconfig -setpolicy argv,acl $ auditconfig -getpolicy audit policies = argv,acl |
新しくポリシーを追加する場合は、ラベル admin_low
でセキュリティ管理者になって、追加するポリシーの前にプラス記号 (+) を付けます。
$ auditconfig -setpolicy trail,seq $ auditconfig -getpolicy audit policies = trail,seq $ auditconfig -setpolicy +argv $ auditconfig -setpolicy +acl $ auditconfig -getpolicy audit policies = seq,trail,argv,acl |
既存のポリシーを削除する場合は、ラベル admin_low
でセキュリティ管理者になって、削除するポリシーの前にマイナス記号 (-) を付けます。
$ auditconfig -setpolicy trail,seq $ auditconfig -getpolicy audit policies = trail,seq $ auditconfig -setpolicy -seq $ auditconfig -getpolicy audit policies = trail |
上の例では、監査トレールの不一致をデバッグするために、trail トークンと seq トークンを追加しています。ポリシーを常時有効にするためには、 audit_startup(1M) スクリプトに auditconfig コマンドを書き込みます。スクリプトの編集方法については、「常時監査ポリシーを設定する方法」を参照してください。
評価済みの構成で監査を実行する場合、cnt ポリシーを設定することはできません。必ず ahlt ポリシーを設定します。
auditconfig(1M) コマンドを使うと、動的に監査フラグを変更することができ、アクティブなユーザーやセッションやプロセスに、別のフラグを追加することができます。フラグは動的に追加されるので、ユーザーのログアウト、セッションの終了、プロセスの終了まで有効です。
特定ユーザーのファイル読み取り成功の監査を追加する場合は、ラベル admin_low
でセキュリティ管理者になって、次のようにします。
$ auditconfig -setumask audit_user_id +fr |
特定セッションのファイル属性アクセス失敗の監査を追加する場合は、ラベル admin_low
でセキュリティ管理者になって、次のようにします。
$ auditconfig -setsmask audit_session_id -fa |
特定プロセスのファイル属性変更の成功と失敗を追加で監査する場合は、ラベル admin_low
でセキュリティ管理者になって、次のようにします。
$ ps -ef | grep application-to-be-monitored $ auditconfig -setpmask process_id fm |
1 回に実行できる監査デーモンは 1 つだけです。同時に複数のデーモンを実行しようとするとエラーメッセージが表示され、新規デーモンは終了します。監査デーモンで問題が発生する場合は、監査デーモンを正常に終了させ、手動で再起動します。
障害発生時に監査デーモンを停止するには、ラベル admin_high
でセキュリティ管理者になって、次のコマンドを入力します。
$ audit -t |
この方法では監査レコードが失われることがあります。注意してください。
監査デーモンは、ワークステーションがマルチユーザーモードに移行すると起動します。また、audit -s コマンドで監査構成ファイルをもう一度読み込むように指示した場合にも起動します。
障害発生時、または監査構成ファイルを変更した場合には、ラベル admin_high
でセキュリティ管理者になって、次のようにして監査デーモンを再起動します。
$ audit -s |