| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11.1 の管理: セキュリティーサービス Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11.1 の管理: セキュリティーサービス Oracle Solaris 11.1 Information Library (日本語) |
パート II システム、ファイル、およびデバイスのセキュリティー
10. Oracle Solaris のセキュリティー属性 (参照)
22. Kerberos エラーメッセージとトラブルシューティング
監査する動作の種類を適切に選択し、有用な監査情報を収集することが望まれます。監査対象者と監査対象も注意して計画する必要があります。デフォルトの audit_binfile プラグインを使用している場合は、監査ファイルが急速に拡大して使用可能な領域がいっぱいになることがあるため、十分なディスク容量を割り当てる必要があります。
次のタスクマップは、ディスク容量および記録対象のイベントを計画するために必要な主なタスクを示しています。
|
システムに非大域ゾーンが含まれている場合は、大域ゾーンを監査する場合と同様にこれらのゾーンを監査できます。あるいは、非大域ゾーンごとの監査サービスを個別に構成したり、有効または無効にしたりできます。たとえば、大域ゾーンを監査せずに、非大域ゾーンのみを監査できます。
トレードオフについては、「Oracle Solaris ゾーンを含むシステムでの監査」を参照してください。
すべてのゾーンを同様に監査する場合、単一イメージの監査トレールが作成される可能性があります。単一イメージの監査トレールは、audit_binfile または audit_remote プラグインを使用しており、システム上のすべてのゾーンが 1 つの管理ドメインに含まれている場合に実行されます。その場合は、すべてのゾーン内のレコードが同一の設定で事前選択されるため、監査レコードを容易に比較できます。
この構成では、すべてのゾーンが 1 つのシステムの一部として扱われます。大域ゾーンはシステム上の唯一の監査サービスを実行し、ゾーンごとに監査レコードを収集します。audit_class および audit_event ファイルは大域ゾーンでのみカスタマイズし、そのあと、これらのファイルをすべての非大域ゾーンにコピーします。
注 - ネームサービスファイルが非大域ゾーンでカスタマイズされ、perzone ポリシーが設定されていない場合は、使用可能なレコードの選択に監査ツールを注意して使用する必要があります。あるゾーン内のユーザー ID は、異なるゾーン内の同じ ID とは異なるユーザーを指している可能性があります。
ゾーン名を監査レコードの一部として含めるには、大域ゾーンで zonename ポリシーを設定します。次に、auditreduce コマンドで、監査証跡からゾーンに基づいて監査イベントを選択できます。例については、auditreduce(1M) のマニュアルページを参照してください。
単一イメージ監査証跡を計画するには、「監査対象者と監査対象イベントの計画方法」を参照してください。最初の手順から始めます。また、大域ゾーン管理者は、「監査レコードのディスク容量を計画する方法」の説明に従ってストレージも確保する必要があります。
ゾーンごとに異なるネームサービスデータベースを使用している場合や、ゾーン管理者が自分のゾーン内の監査を制御する場合は、ゾーンごとの監査を構成することを選択します。
注 - 非大域ゾーンを監査するには perzone ポリシーを設定する必要がありますが、大域ゾーンで監査サービスを有効にする必要はありません。非大域ゾーンの監査は大域ゾーンとは別に構成し、その監査サービスも大域ゾーンとは別に有効または無効にします。
ゾーンごとの監査を構成する場合は、大域ゾーンで perzone 監査ポリシーを設定します。非大域ゾーンが最初にブートされる前にゾーンごとの監査が設定されている場合は、そのゾーンの最初のブート時に監査が開始されます。監査ポリシーを設定するには、「ゾーンごとの監査を構成する方法」を参照してください。
各ゾーン管理者がゾーンの監査を構成します。
非大域ゾーン管理者は、perzone と ahlt 以外のすべてのポリシーオプションを設定できます。
各ゾーン管理者はゾーン内で監査を有効化または無効化できます。
ゾーンごとの監査を計画するには、「監査対象者と監査対象イベントの計画方法」を参照してください。最初の手順は省略できます。audit_binfile プラグインがアクティブな場合、各ゾーン管理者は 「監査レコードのディスク容量を計画する方法」の説明に従って、すべてのゾーンのストレージも確保する必要があります。
始める前に
非大域ゾーンを実装している場合は、この手順を使用する前に、「ゾーン内の監査の計画方法」を確認してください。
注 - この手順は、audit_binfile プラグインにのみ適用されます。
システムが単一の管理ドメイン内にある場合、単一システムイメージの監査トレールを作成できます。システムで別のネームサービスが使用されている場合は、手順 2 から始めてください。次に、システムごとに、計画の手順の残りを完了します。
サイト用の単一システムイメージ監査トレールを作成するには、インストール内のすべてのシステムを次のように構成する必要があります。
すべてのシステムで同じネームサービスを使用します。
監査レコードの正しい解釈のためには、passwd、group、および hosts ファイルの整合性がとれている必要があります。
すべてのシステム上で監査サービスを同様に構成します。サービス設定の表示および変更については、auditconfig(1M) のマニュアルページを参照してください。
すべてのシステムで同じ audit_warn、audit_event、および audit_class ファイルを使用します。
デフォルトでは、cnt ポリシーだけが有効になっています。
使用可能なポリシーオプションの説明を表示するには、auditconfig -lspolicy コマンドを使用します。
ポリシーオプションの効果については、「監査ポリシーについて」を参照してください。
cnt ポリシーの効果については、「非同期イベントおよび同期イベントの監査ポリシー」を参照してください。
監査ポリシーを設定するには、「監査ポリシーを変更する方法」を参照してください。
ほぼすべての状況で、デフォルトのマッピングをそのまま使用できます。ただし、新しいクラスを追加したり、クラス定義を変更したりする場合や、特定のシステムコールのレコードが有効でないと判断される場合は、イベントからクラスへのマッピングを変更することもできます。
例は、「監査イベントの所属先クラスの変更方法」を参照してください。
監査クラスを追加したり、デフォルトのクラスを変更したりするには、ユーザーがシステムにログインする前に行うのが最適です。
auditconfig コマンドの -setflags および -setnaflags オプションを使用して事前選択した監査クラスは、すべてのユーザーとプロセスに適用されます。成功、失敗、またはその両方に対してクラスを事前選択できます。
監査クラスの一覧については、/etc/security/audit_class ファイルを参照してください。
一部のユーザーをシステムとは異なる方法で監査した方がよいと判断される場合は、個々のユーザーまたは権利プロファイルに対する audit_flags セキュリティー属性を変更できます。ユーザーの事前選択マスクは、監査フラグが明示的に設定されているユーザー、または明示的な監査フラグを含む権利プロファイルが割り当てられているユーザーに対して変更されます。
手順については、「ユーザーの監査特性を構成する方法」を参照してください。どの監査フラグの値が有効かについては、「割り当てられたセキュリティー属性の検索順序」を参照してください。
audit_warn スクリプトは、監査システムによって管理上の注意が必要な状況が検出されたときは常に実行されます。デフォルトでは、audit_warn スクリプトは、audit_warn のエイリアスに電子メールを送信し、コンソールにメッセージを送信します。
エイリアスを設定するには、「audit_warn 電子メールエイリアスの構成方法」を参照してください。
次の 3 つの選択肢があります。
デフォルトでは、バイナリ監査レコードをローカルに格納します。デフォルトの格納ディレクトリは /var/audit です。audit_binfile プラグインをさらに構成するには、「監査ファイルのための ZFS ファイルシステムを作成する方法」を参照してください。
audit_remote プラグインを使用して、バイナリ監査レコードを保護されたリモートリポジトリにストリーム出力します。レコードの受信者が存在する必要があります。要件については、「リモートリポジトリの管理」を参照してください。手順については、「監査ファイルをリモートリポジトリに送信する方法」を参照してください。
audit_syslog プラグインを使用して、監査レコードの概要を syslog に送信します。手順については、「syslog 監査ログの構成方法」を参照してください。
バイナリ形式と syslog 形式の比較については、「監査ログ」を参照してください。
注 - この手順は、audit_binfile プラグインにのみ適用されます。
監査ファイルシステム上のディスク容量が最小空き容量の割合 (または、弱い制限値) を下回ると、監査サービスは次に使用可能な監査ディレクトリに切り替えます。このサービスは次に、弱い制限値を超えたことを示す警告を送信します。
最小空き容量の割合を設定するには、例 28-17 を参照してください。
注 - この手順は、audit_binfile プラグインにのみ適用されます。
デフォルトの構成では、audit_binfile プラグインがアクティブであり、cnt ポリシーが設定されます。この構成では、カーネル監査キューがいっぱいになっても、システムは動作し続けます。システムは破棄された監査レコードを数えますが、イベントを記録しません。セキュリティーをより向上させるためには、cnt ポリシーを無効にして、ahlt ポリシーを有効にします。ahlt ポリシーは、非同期イベントが監査キューに配置できない場合、システムを停止します。
これらのポリシーオプションについては、「非同期イベントおよび同期イベントの監査ポリシー」を参照してください。これらのポリシーオプションを構成するには、例 28-6 を参照してください。
ただし、audit_binfile キューがいっぱいになったときに、別のアクティブなプラグインのキューがいっぱいでない場合、カーネルキューは、そのいっぱいでないプラグインにレコードを送信し続けます。audit_binfile キューがふたたびレコードを受け入れることができるようになると、監査サービスは、そのキューへのレコードの送信を再開します。
注 - cnt または ahlt ポリシーは、少なくとも 1 つのプラグインのキューが監査レコードを受け入れている場合はトリガーされません。
audit_binfile プラグインは、監査トレールを作成します。監査トレールには専用のファイル領域が必要です。この領域は使用可能で、セキュリティー保護されている必要があります。システムは、初期のストレージとして /var/audit ファイルシステムを使用します。監査ファイルのための追加の監査ファイルシステムを構成できます。次の手順は、監査トレールのストレージを計画するときに解決する必要のある問題について説明しています。
始める前に
非大域ゾーンを実装している場合は、この手順を行う前に 「ゾーン内の監査の計画方法」の手順を完了してください。
audit_binfile プラグインを使用しています。
サイトのセキュリティー上の必要性を考慮して、監査トレールに使用できるディスク容量を決定します。
サイトのセキュリティーを確保しながら領域要件を削減する方法と、監査ストレージを設定する方法については、「監査コストの制御」と 「効率的な監査」を参照してください。
実際的な手順については、「生成される監査レコードの量を削減する方法」、「専用ファイルシステム上の監査ファイルを圧縮する方法」、および例 28-30 を参照してください。
使用を予定しているすべてのファイルシステムの一覧を作成します。構成ガイドラインについては、「監査トレールの格納および管理」および auditreduce(1M) のマニュアルページを参照してください。監査ファイルシステムを指定するには、「監査トレールのための監査領域を割り当てる方法」を参照してください。
詳細は、「信頼性の高いタイムスタンプの保証」を参照してください。
注 - Kerberos レルムが構成されており、そのレルム内に識別された監査リモートサーバー (ARS) とすべての監査対象システムが存在する場合は、この手順をスキップできます。ARS と監査対象システムを構成する手順については、「監査ファイルのためのリモートリポジトリを構成する方法」および「監査ファイルをリモートリポジトリに送信する方法」で説明されています。
audit_remote プラグインは、バイナリの監査トレールを、audit_binfile プラグインがローカル監査ファイルに書き込むのと同じ形式で ARS に送信します。audit_remote プラグインは、libgss ライブラリを使用して ARS を認証し、GSS-API メカニズムを使用してプライバシと完全性により転送を保護します。参照情報については、「Kerberos サービスとは」および 「Kerberos のコンポーネント」を参照してください。
現在サポートされている GSS-API メカニズムは kerberosv5 だけです。詳細は、mech(4) のマニュアルページを参照してください。
始める前に
audit_remote プラグインの使用を計画しています。
ARS として機能するシステムを使用するか、または近くのシステムを使用できます。ARS は、大量の認証トラフィックをマスター KDC に送信します。
システム上に Kerberos パッケージがすでに存在する場合は、次のような出力が表示されます。
# pkg search -l kerberos-5 INDEX ACTION VALUE PACKAGE pkg.summary set Kerberos version 5 support pkg:/service/security/kerberos-5@vn pkg.summary set Kerberos V5 Master KDC pkg:/system/security/kerberos-5@vn
最初のコマンドは、Kerberos V5 マスター KDC パッケージがインストールされているかどうかを確認します。2 番目のコマンドは、このパッケージをインストールします。
# pkg info system/security/kerberos-5 pkg: info: no packages matching these patterns are installed on the system. # pkg install pkg:/system/security/kerberos-5
マスター KDC 上では、Kerberos kdcmgr および kadmin コマンドを使用してレルムを管理します。参照情報については、kdcmgr(1M) および kadmin(1M) のマニュアルページを参照してください。
# pkg install pkg:/system/security/kerberos-5
このパッケージには kclient コマンドが含まれています。これらのシステム上では、kclient コマンドを実行して KDC と接続します。参照情報については、kclient(1M) のマニュアルページを参照してください。
監査対象システムと ARS の間のクロックスキューが大きすぎる場合は、接続の試行が失敗します。接続が確立されると、「バイナリ監査ファイルの命名規則」で説明されているように、ARS 上のローカル時間によって格納される監査ファイルの名前が決定されます。
クロックの詳細は、「信頼性の高いタイムスタンプの保証」を参照してください。
|