JavaScript is required to for searching.
ナビゲーションリンクをスキップ
印刷ビューの終了
Solaris のシステム管理 (セキュリティサービス)     Oracle Solaris 10 8/11 Information Library (日本語)
search filter icon
search icon

ドキュメントの情報

はじめに

パート I セキュリティーの概要

1.  セキュリティーサービス (概要)

パート II システム、ファイル、およびデバイスのセキュリティー

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

3.  システムアクセスの制御 (作業)

4.  デバイスアクセスの制御 (作業)

5.  基本監査報告機能の使用方法 (作業)

6.  ファイルアクセスの制御 (作業)

7.  自動セキュリティー拡張ツールの使用 (手順)

パート III 役割、権利プロファイル、特権

8.  役割と特権の使用 (概要)

9.  役割によるアクセス制御の使用 (手順)

10.  役割によるアクセス制御 (参照)

11.  特権 (手順)

12.  特権 (参照)

パート IV 暗号化サービス

13.  Oracle Solaris の暗号化フレームワーク (概要)

14.  Oracle Solaris の暗号化フレームワーク (手順)

15.  Oracle Solaris 鍵管理フレームワーク

パート V 認証サービスと安全な通信

16.  認証サービスの使用 (手順)

17.  PAM の使用

18.  SASL の使用

19.  Oracle Solaris Secure Shell の使用 (手順)

20.  Oracle Solaris Secure Shell (参照)

パート VI Kerberos サービス

21.  Kerberos サービスについて

22.  Kerberos サービスの計画

23.  Kerberos サービスの構成 (手順)

24.  Kerberos エラーメッセージと障害追跡

25.  Kerberos 主体とポリシーの管理 (手順)

26.  Kerberos アプリケーションの使用 (手順)

27.  Kerberos サービス (参照)

パート VII Oracle Solaris 監査

28.  Oracle Solaris 監査 (概要)

29.  Oracle Solaris 監査の計画

30.  Oracle Solaris 監査の管理 (手順)

Oracle Solaris 監査 (作業マップ)

監査ファイルの構成 (作業マップ)

監査ファイルの構成 (手順)

audit_control ファイルの変更方法

syslog 監査ログの構成方法

ユーザーの監査特性の変更方法

監査クラスの追加方法

監査イベントの所属先クラスの変更方法

監査サービスの構成と有効化 (作業マップ)

監査サービスの構成と有効化 (手順)

監査ファイルのパーティションの作成方法

audit_warn 電子メールエイリアスの構成方法

監査ポリシーを構成する方法

監査サービスを有効にする方法

監査サービスを無効にする方法

監査サービスの更新方法

ゾーンでの監査サービスの構成 (手順)

すべてのゾーンの監査を同様に構成する方法

ゾーンごとの監査を構成する方法

監査レコードの管理 (作業マップ)

監査レコードの管理

監査レコードの書式の表示方法

監査トレールの監査ファイルをマージする方法

監査トレールから監査イベントを選択する方法

バイナリ監査ファイルの内容を表示する方法

not_terminated 監査ファイルを整理する方法

監査トレールのオーバーフローを防ぐ方法

Oracle Solaris 監査の障害追跡 (手順)

Oracle Solaris 監査の障害追跡 (作業マップ)

Oracle Solaris 監査が実行中であるかどうかを判定する方法

生成される監査レコードの量を削減する方法

ユーザーによるすべてのコマンドを監査する方法

特定のファイルに対する変更の監査レコードを検索する方法

ユーザーの事前選択マスクを変更する方法

特定のイベントが監査されないようにする方法

バイナリ監査ファイルのサイズを制限する方法

ほかの OS からのログインを監査する方法

FTP および SFTP ファイル転送を監査する方法

31.  Oracle Solaris 監査 (参照)

用語集

索引

監査サービスの構成と有効化 (手順)

構成ファイルをサイト用に構成したあと、監査ファイルのディスク容量を設定する必要があります。監査サービスのほかの属性を設定して、サービスを有効にする必要もあります。この節では、構成の設定を変更したときに監査サービスを更新する手順も説明します。

非大域ゾーンがインストールされている場合、監査対象の大域ゾーンと同じようにゾーンを監査することができます。非大域ゾーンを別々に監査する場合は、非大域ゾーンの監査構成ファイルを変更することができます。監査構成ファイルをカスタマイズする方法については、「監査ファイルの構成 (作業マップ)」を参照してください。

監査ファイルのパーティションの作成方法

次の手順では、監査ファイル用のパーティションの作成方法、および監査に対応するファイルシステムとディレクトリの作成方法について説明します。すでに空のパーティションがある場合、またはすでに空のファイルシステムをマウントしている場合は、必要に応じて手順を省略してください。

  1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

  2. 必要なディスク容量を決定します。

    ホストごとに 200M バイト以上を割り当てます。ただし、必要な監査の量によりディスク容量要件が決まります。つまり、要件によっては、この数値を超えることもあります。予備ディレクトリのローカルパーティション領域も含めてください。

  3. 必要に応じて、監査パーティションを作成します。

    この手順は、サーバーのインストール時に実行するのがもっとも簡単です。サーバーにマウントされていないディスク上にパーティションを作成することもできます。パーティションの作成方法については、『Solaris のシステム管理 (デバイスとファイルシステム)』の第 11 章「ディスクの管理 (手順)」を参照してください。

    # newfs /dev/rdsk/cwtxdysz

    この例で、 /dev/rdsk/cwt xdysz は、パーティションの raw デバイス名です。

    ローカルホストを監査する場合は、ローカルホスト用に予備の監査ディレクトリも作成します。

  4. 新しいパーティションのマウント先を作成します。
    # mkdir /var/audit/server-name.n

    server-name.n は、サーバー名と各パーティションの識別番号を結合したものです。この識別番号は省略できますが、多数の監査ディレクトリを作成する場合はこの番号を使用すると便利です。

  5. 新しいパーティションを自動的にマウントするエントリを追加します。

    /etc/vfstab ファイルに次のような行を追加します。

    /dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n   ufs  2  yes
  6. (省略可能) 各パーティションの最小空き容量のしきい値を削除します。

    デフォルトの構成を使用した場合、ディレクトリの 80% がいっぱいになった時点で警告が生成されます。このため、パーティション上に空き容量を予約する必要はありません。

    # tunefs -m 0 /var/audit/server-name.n
  7. 新しい監査パーティションをマウントします。
    # mount /var/audit/server-name.n
  8. 新しいパーティションに監査ディレクトリを作成します。
    # mkdir /var/audit/server-name.n/files
  9. マウント先と新しいディレクトリへのアクセス権を訂正します。
    # chmod -R 750 /var/audit/server-name.n/files
  10. ファイルサーバー上で、ほかのホストからアクセスできるファイルシステムを定義します。

    監査レコードを格納するために、ディスクファームをインストールすることがよく行われます。監査ディレクトリを複数のシステムで使用する場合は、そのディレクトリを NFS サービスを通して共有する必要があります。/etc/dfs/dfstab ファイルに対して、次のようなエントリをディレクトリごとに追加します。

    share -F nfs /var/audit/server-name.n/files
  11. ファイルサーバー上で、NFS サービスを起動し直します。

    このコマンドが、ユーザーが起動した最初の 1 つまたは複数の share コマンドの場合、NFS デーモンが実行されていないことがあります。

    • NFS サービスがオフラインの場合、サービスを有効にします。
      % svcs \*nfs\*
      disabled       Nov_02   svc:/network/nfs/rquota:default
      offline        Nov_02   svc:/network/nfs/server:default
      # svcadm enable network/nfs/server
    • NFS サービスが実行中の場合、サービスを再起動します。
      % svcs \*nfs\*
      online         Nov_02   svc:/network/nfs/client:default
      online         Nov_02   svc:/network/nfs/server:default
      # svcadm restart network/nfs/server

    NFS サービスの詳細は、『Solaris のシステム管理 (ネットワークサービス)』の「NFS サービスの設定」を参照してください。永続的なサービスの管理の詳細は、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」および smf(5) のマニュアルページを参照してください。

例 30-13 予備の監査ディレクトリを作成する

監査サービスを実行するすべてのシステムには、利用できるファイルシステムがほかにない場合に使用するローカルファイルシステムが必要です。この例では、ファイルシステムが egret という名前のシステムに追加されます。このファイルシステムは、ローカルシステムだけで使用されるため、ファイルサーバーの手順は必要ありません。

# newfs /dev/rdsk/c0t2d0
# mkdir /var/audit/egret
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret ufs  2  yes  -
# tunefs -m 0 /var/audit/egret
# mount /var/audit/egret
# mkdir /var/audit/egret/files
# chmod -R 750 /var/audit/egret/files

例 30-14 新しい監査パーティションを作成する

この例では、新しいファイルシステムが、2 つの新しいディスクに作成されます。この 2 つのディスクは、ネットワーク上のほかのシステムと共有します。

# newfs /dev/rdsk/c0t2d0
# newfs /dev/rdsk/c0t2d1
# mkdir /var/audit/egret.1
# mkdir /var/audit/egret.2
# grep egret /etc/vfstab
/dev/dsk/c0t2d0s1  /dev/rdsk/c0t2d0s1  /var/audit/egret.1 ufs  2  yes  -
/dev/dsk/c0t2d1s1  /dev/rdsk/c0t2d1s1  /var/audit/egret.2 ufs  2  yes  -
# tunefs -m 0 /var/audit/egret.1
# tunefs -m 0 /var/audit/egret.2
# mount /var/audit/egret.1
# mount /var/audit/egret.2
# mkdir /var/audit/egret.1/files
# mkdir /var/audit/egret.2/files
# chmod -R 750 /var/audit/egret.1/files /var/audit/egret.2/files
# grep egret /etc/dfs/dfstab
 share -F nfs /var/audit/egret.1/files
 share -F nfs /var/audit/egret.2/files
# svcadm enable network/nfs/server

例 30-15 ZFS 監査パーティションを作成する

この例では、管理者は、ZFS 監査パーティションの作成後に script コマンドを実行します。コマンドの出力は次のとおりです。

# zpool create auditf mirror c0t4d0 c0t5d0
# zfs create -o mountpoint=/audit auditf/audit
# zfs create auditf/audit/noddy
# zfs create auditf/audit/noddy/files
# zfs create auditf/audit/blinken
# zfs create auditf/audit/blinken/files
# zfs set devices=off auditf/audit
# zfs set exec=off auditf/audit
# zfs set setuid=off auditf/audit
# zfs set sharenfs=on auditf/audit
# share
-               /audit/blinken/files   rw   ""
-               /audit/noddy   rw   ""
-               /audit/blinken   rw   ""
-               /audit/noddy/files   rw   ""
-               /audit   rw   ""
# ^D
script done on Fri Apr 10 10:10:20 2009

次に、遠隔システム remotesys からのマウントを表示します。

# dfshares remotesys
RESOURCE                             SERVER ACCESS    TRANSPORT
remotesys:/audit/blinken/files       remotesys  -         -
remotesys:/audit/noddy               remotesys  -         -
remotesys:/audit/blinken             remotesys  -         -
remotesys:/audit/noddy/files         remotesys  -         -
remotesys:/audit                     remotesys  -         -

最後に、/audit ファイルシステムを /var/audit にマウントします。

# mount remotesys:/audit /var/audit
# ls /var/audit
blinken  noddy 

audit_warn 電子メールエイリアスの構成方法

audit_warn スクリプトは、audit_warn という電子メールエイリアスに対してメールを生成します。有効な電子メールアドレスにこのメールを送信するには、手順 2 で説明するオプションのいずれか 1 つに従います。

  1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

  2. audit_warn 電子メールエイリアスを構成します。

    次のオプションのいずれかを選択します。

    • オプション 1 – audit_warn スクリプトで、audit_warn 電子メールエイリアスをほかの電子メールアカウントに置き換えます。

      スクリプトの次の行で電子メールエイリアスを変更します。

      ADDRESS=audit_warn            # standard alias for audit alerts
    • オプション 2 – audit_warn 電子メールをほかの電子メールアカウントにリダイレクトします。

      この場合、audit_warn 電子メールエイリアスを適切なメールエイリアスファイルに追加します。別名の追加先として、ローカルの /etc/mail/aliases ファイル、名前空間の mail_aliases データベースのいずれかを選択します。root 電子メールアカウントを audit_warn 電子メールエイリアスのメンバーとして登録する場合、新しいエントリは次のようになります。

      audit_warn: root

監査ポリシーを構成する方法

監査ポリシーを使用して、ローカルホストの監査レコードの特性を決定します。監査が有効な場合、/etc/security/audit_startup ファイルの内容により、監査ポリシーが決まります。

auditconfig コマンドを使用すると、現在の監査ポリシーオプションを検査および変更できます。また、監査ポリシーの変更内容を固定するために、audit_startup スクリプト内で auditconfig コマンドの監査ポリシーオプションを変更することも可能です。

  1. Audit Control プロファイルを含む役割を引き受けるか、スーパーユーザーになります。

    Audit Control プロファイルを含む役割を作成する方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

  2. 監査ポリシーを確認します。

    監査を有効にする前に、audit_startup ファイルの内容により、監査ポリシーが決まります。

    #! /bin/sh
    ...
    /usr/bin/echo "Starting BSM services."
    /usr/sbin/auditconfig -setpolicy +cnt Counts rather than drops records
    /usr/sbin/auditconfig -conf  Configures event-class mappings
    /usr/sbin/auditconfig -aconf Configures nonattributable events
  3. 使用可能なポリシーオプションを表示します。
    $ auditconfig -lspolicy

    注 - perzoneahlt ポリシーオプションは、大域ゾーンでのみ設定できます。


  4. 選択した監査ポリシーオプションを有効または無効にします。
    # auditconfig -setpolicy prefixpolicy
    prefix

    prefix+ を指定するとポリシーオプションが有効になります。prefix- を指定するとポリシーオプションが無効になります。

    policy

    有効または無効にするポリシーを選択します。

    このポリシーの設定は、次回ブートするまで、または auditconfig setpolicy コマンドを使ってポリシーを変更するまで持続します。

    各ポリシーオプションの詳細は、「監査ポリシーの決定」を参照してください。

例 30-16 cnt および ahlt 監査ポリシーオプションを設定する

この例では、cnt ポリシーが無効になり、ahlt ポリシーが有効になります。これらの設定では、監査パーティションがいっぱいで非同期イベントが発生した場合、システムの使用が停止します。同期イベントが発生すると、スレッドを作成したプロセスがハングアップします。これらの設定は、セキュリティーが可用性よりも重要な場合に適しています。

次の audit_startup エントリによって、再起動を行なっても cnt ポリシーオプションが無効で ahlt ポリシーを有効のままになります。

# cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy -cnt    
/usr/sbin/auditconfig -setpolicy +ahlt

例 30-17 seq 監査ポリシーを一時的に設定する

この例では、auditd デーモンが実行中で、ahlt 監査ポリシーが設定されています。seq 監査ポリシーが現在のポリシーに追加されます。seq ポリシーは、sequence トークンをすべての監査レコードに追加します。監査レコードが破壊されたときやレコードが破棄されているとき、監査サービスのデバッグに役立ちます。

+ 接頭辞により、現在の監査ポリシーを seq に置き換えるのではなく、seq オプションが監査ポリシーに追加されます。auditconfig コマンドにより、ポリシーはコマンドが次に起動するまで、または次のブートまで有効になります。

$ auditconfig -setpolicy +seq
$ auditconfig -getpolicy
audit policies = ahlt,seq    

例 30-18 perzone 監査ポリシーを設定する

この例では、perzone 監査ポリシーが、大域ゾーンの audit_startup スクリプト内で設定されます。ゾーンのブート時に、非大域ゾーンは、そのゾーン内の監査構成設定に関する監査レコードを収集します。

$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +perzone
/usr/sbin/auditconfig -setpolicy +cnt

例 30-19 監査ポリシーを変更する

この例では、auditd デーモンが実行中で、監査ポリシーが設定されています。auditconfig コマンドは、セッションの間、ahltcnt ポリシーを変更します。これらの設定により、監査ファイルシステムがいっぱいになると、監査レコードは破棄されますが、カウントされます。ahlt ポリシーの設定での制限については、手順 3 を参照してください。

$ auditconfig -setpolicy +cnt
$ auditconfig -setpolicy -ahlt
$ auditconfig -getpolicy
audit policies = cnt,seq

変更をaudit_startup ファイルに書き込むと、ポリシーは永続的に有効になります。

$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +cnt

ahlt ポリシーはデフォルトで無効になっているため、-ahlt オプションをファイル内で指定する必要はありません。この設定は、監査レコードのセキュリティーよりも可用性が重要な場合に適しています。

監査サービスを有効にする方法

この手順では、監査サービスをすべてのゾーンで有効にします。非大域ゾーンで監査デーモンを起動するには、例 30-20 を参照してください。

監査が安全に構成されると、監査が有効化されるまで、システムはシングルユーザーモードになります。マルチユーザーモードで監査を有効にすることもできます。

始める前に

次の作業を完了してから、この手順をスーパーユーザーとして実行してください。


注 - 監査が成功するには、ホスト名変換が正しく機能している必要があります。ネームサービスの hosts データベースが正しく構成され、機能している必要があります。

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


  1. 監査サービスを有効にするスクリプトを実行します。

    /etc/security ディレクトリに移動し、bsmconv スクリプトを実行します。

    # cd /etc/security
    # ./bsmconv
    This script is used to enable the Basic Security Module (BSM).
    Shall we continue with the conversion now? [y/n] y
    bsmconv: INFO: checking startup file.
    bsmconv: INFO: turning on audit module.
    bsmconv: INFO: initializing device allocation.
    
    The Basic Security Module is ready.
    If there were any errors, please fix them now.
    Configure BSM by editing files located in /etc/security.
    Reboot this system now to come up with BSM enabled.

    スクリプトの働きについては、bsmconv(1M) のマニュアルページを参照してください。

  2. システムを再起動します。
    # reboot

    システムがマルチユーザーモードに移行すると、起動ファイル /etc/security/audit_startup によって auditd デーモンが自動的に動作します。

    スクリプトのもう 1 つの働きは、デバイス割り当てを有効にすることです。デバイス割り当ての設定方法は、「デバイス割り当ての管理 (作業マップ)」を参照してください。

例 30-20 非大域ゾーンで監査を有効にする

次の例では、監査が大域ゾーンで有効になり非大域ゾーンがブートされたあと、大域ゾーン管理者が perzone ポリシーを有効にします。非大域ゾーンのゾーン管理者は、ゾーンの監査ファイルを構成して、ゾーンで監査デーモンを起動します。

zone1# svcadm enable svc:/system/auditd

監査サービスを無効にする方法

ある時点で監査サービスが不要になった場合、この手順は監査が有効になる前のシステム状態にシステムを戻します。非大域ゾーンが監査されている場合は、その監査サービスも無効になります。


注意

注意 - このコマンドによって、デバイス割り当ても無効になります。デバイス割り当てを可能にする場合は、このコマンドを実行しないでください。デバイス割り当てを保ったまま監査を無効にする方法については、例 30-21 を参照してください。


  1. スーパーユーザーになり、システムをシングルユーザーモードにします。
    % su
    Password: <Type root password>
    # init S

    詳細は、init(1M) のマニュアルページを参照してください。

  2. スクリプトを実行して、監査を無効にします。

    /etc/security ディレクトリに移動し、bsmunconv スクリプトを実行します。

    # cd /etc/security
    # ./bsmunconv

    スクリプトのもう 1 つの働きは、デバイス割り当てを無効にすることです。

    bsmunconv スクリプトの詳細は、bsmconv(1M) のマニュアルページを参照してください。

  3. システムをマルチユーザーモードにします。
    # init 6

例 30-21 デバイス割り当てを保持したまま監査を無効にする

この例では、監査サービスはレコードの収集を停止しますが、デバイス割り当ては引き続き機能します。audit_user ファイルのすべてのユーザーエントリと同様に、audit_control ファイルの flagsnaflags、 および plugin エントリからのすべての値が削除されます。

## audit_control file
flags:
naflags:

## audit_user file

auditd デーモンが実行されますが、監査レコードは保持されません。

例 30-22 監査をゾーン単位で無効にする

この例では、監査サービスが無効化された zone1 内で、監査サービスが実行を停止します。デバイス割り当ては引き続き機能します。perzone 監査ポリシーが設定されていない状態で、このコマンドが大域ゾーンで実行されると、大域ゾーンだけでなくすべてのゾーンで監査が無効になります。

zone1 # audit -t

監査サービスの更新方法

この手順では、デーモの実行中に監査構成ファイルを変更した場合に、auditd デーモンを再起動します。

  1. Audit Control 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。

    Audit Control 権利プロファイルを含む役割の作成方法およびユーザーに役割を割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

  2. 適切なコマンドを選択します。
    • audit_control ファイルの naflags 行を変更する場合は、ユーザーに起因しないイベント用のカーネルマスクを変更します。
      $ /usr/sbin/auditconfig -aconf

      リブートすることもできます。

    • audit_control ファイルのほかの行を変更する場合は、audit_control ファイルを再度読み込みます。

      監査デーモンは、audit_control ファイルからの情報を内部で格納します。新しい情報を使用するには、システムを再起動するか、または変更されたファイルを監査デーモンが読み込むようにします。

      $ /usr/sbin/audit -s

      注 - 監査レコードは、各プロセスに関連付けられた監査事前選択マスクに基づいて生成されます。audit -s を実行しても、既存のプロセス内のマスクは変更されません。既存プロセスの事前選択マスクを変更するには、プロセスを再起動する必要があります。リブートすることもできます。


      audit -s コマンドを使用すると、監査デーモンはディレクトリと最小限の空きの値を audit_control ファイルから再度読み取ります。このコマンドにより、後続のログインにより発生するプロセス用の事前選択マスクの生成が変更されます。

    • 監査デーモンの実行中に audit_event ファイルまたは audit_class ファイルを変更する場合は、監査サービスを再表示します。

      変更したイベントからクラスへのマッピングをシステムに読み込み、マシンを使用する各ユーザーが正しく監査されているかを確認します。

      $ auditconfig -conf
      $ auditconfig -setumask auid classes
      auid

      ユーザー ID です。

      classes

      事前に選択された監査クラスです。

      例については、「ユーザーの事前選択マスクを変更する方法」を参照してください。

    • 稼動中のシステムで監査ポリシーを変更するには、例 30-17 を参照してください。

例 30-23 監査デーモンを再起動する

この例では、システムをシングルユーザーモードにしたあとで、マルチユーザーモードに戻します。システムがマルチユーザーモードになったとき、変更された構成ファイルがシステムに読み込まれます。

# init S
# init 6