手順

1. システム全体の暗号化ポリシーを LEGACY レベルに切り替えるには、root で以下のコマンドを実行します。

   # update-crypto-policies --set LEGACY
   Setting system policy to LEGACY

手順

1. RHEL 8 で FIPS モードにシステムを切り替えるには、以下のコマンドを実行します。

   # fips-mode-setup --enable
   Setting system policy to FIPS
   FIPS mode will be enabled.
   Please reboot the system for the setting to take effect.

2. システムを再起動して、カーネルを FIPS モードに切り替えます。

   # reboot

検証

1. システムが再起動したら、FIPS モードの現在の状態を確認できます。

   # fips-mode-setup --check
   FIPS mode is enabled.

手順

1. /etc/crypto-policies/policies/modules/ ディレクトリーをチェックアウトします。

   # cd /etc/crypto-policies/policies/modules/

2. 以下のように、調整用のポリシーモジュールを作成します。

   # touch MYCRYPTO1.pmod
   # touch NO-AES128.pmod

   重要

   ポリシーモジュールのファイル名には大文字を使用します。

3. 任意のテキストエディターでポリシーモジュールを開き、システム全体の暗号化ポリシーを変更するオプションを挿入します。次に例を示します。

   # vi MYCRYPTO1.pmod

   sha1_in_certs = 0
   min_rsa_size = 3072

   # vi NO-AES128.pmod

   cipher = -AES-128-GCM -AES-128-CCM -AES-128-CTR -AES-128-CBC

4. 変更をモジュールファイルに保存します。

5. ポリシーの調整を、システム全体の暗号化ポリシーレベル DEFAULT に適用します。

   # update-crypto-policies --set DEFAULT:MYCRYPTO1:NO-AES128

6. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

   # reboot

手順

1. ポリシーの調整を、システム全体の暗号化ポリシーレベル DEFAULT に適用します。

   # update-crypto-policies --set DEFAULT:NO-SHA1

2. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

   # reboot

手順

1. カスタマイズのポリシーファイルを作成します。

   # cd /etc/crypto-policies/policies/
   # touch MYPOLICY.pol

   または、定義されている 4 つのポリシーレベルのいずれかをコピーします。

   # cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/MYPOLICY.pol

2. 必要に応じて、テキストエディターでファイルを編集します。以下のようにしてカスタム暗号化ポリシーを使用します。

   # vi /etc/crypto-policies/policies/MYPOLICY.pol

3. システム全体の暗号化ポリシーをカスタムレベルに切り替えます。

   # update-crypto-policies --set MYPOLICY

4. 暗号化設定を実行中のサービスやアプリケーションで有効にするには、システムを再起動します。

   # reboot

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   ---
   - hosts: all
     tasks:
     - name: Configure crypto policies
       include_role:
         name: linux-system-roles.crypto_policies
       vars:
         - crypto_policies_policy: FUTURE
         - crypto_policies_reboot_ok: true

   FUTURE の値は、任意の暗号化ポリシー (例: DEFAULT、LEGACY、および FIPS:OSPP) に置き換えることができます。

   crypto_policies_reboot_ok: true 変数を設定すると、システムロールで crypto ポリシーを変更した後にシステムが再起動されます。

   詳細は「Crypto Policies システムロール変数およびファクト」を参照してください。

2. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check playbook.yml

3. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file playbook.yml

検証

1. コントロールノードで (例: verify_playbook.yml) という名前の別の Playbook を作成します。

   - hosts: all
     tasks:
    - name: Verify active crypto policy
      include_role:
        name: linux-system-roles.crypto_policies
   
    - debug:
        var: crypto_policies_active

   この Playbook では、システムの設定は変更されず、管理対象ノードのアクティブなポリシーだけを報告します。

2. 同じインベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory_file verify_playbook.yml
   
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   "crypto_policies_active": 変数は、管理対象ノードでアクティブなポリシーを表示します。

手順

1. PKCS #11 の URI を含む OpenSC PKCS #11 モジュールが提供する鍵の一覧を表示し、その出力を keys.pub ファイルに保存します。

   $ ssh-keygen -D pkcs11: > keys.pub
   $ ssh-keygen -D pkcs11:
   ssh-rsa AAAAB3NzaC1yc2E...KKZMzcQZzx pkcs11:id=%02;object=SIGN%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so
   ecdsa-sha2-nistp256 AAA...J0hkYnnsM= pkcs11:id=%01;object=PIV%20AUTH%20pubkey;token=SSH%20key;manufacturer=piv_II?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so

2. リモートサーバー (example.com) でスマートカードを使用した認証を有効にするには、公開鍵をリモートサーバーに転送します。前の手順で作成された keys.pub で ssh-copy-id コマンドを使用します。

   $ ssh-copy-id -f -i keys.pub username@example.com

3. 手順 1 の ssh-keygen -D コマンドの出力にある ECDSA 鍵を使用して example.com に接続するには、鍵を一意に参照する URI のサブセットのみを使用できます。以下に例を示します。

   $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" example.com
   Enter PIN for 'SSH key':
   [example.com] $

4. ~/.ssh/config ファイルで同じ URI 文字列を使用して、設定を永続化できます。

   $ cat ~/.ssh/config
   IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so"
   $ ssh example.com
   Enter PIN for 'SSH key':
   [example.com] $

   OpenSSH は p11-kit-proxy ラッパーを使用し、OpenSC PKCS #11 モジュールが PKCS#11 キットに登録されているため、以前のコマンドを簡素化できます。

   $ ssh -i "pkcs11:id=%01" example.com
   Enter PIN for 'SSH key':
   [example.com] $

手順

1. システムで信頼されている CA の一覧に、シンプルな PEM または DER のファイルフォーマットに含まれる証明書を追加するには、/usr/share/pki/ca-trust-source/anchors/ ディレクトリーまたは /etc/pki/ca-trust/source/anchors/ ディレクトリーに証明書ファイルをコピーします。以下に例を示します。

   # cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/

2. システム全体のトラストストア設定を更新するには、update-ca-trust コマンドを実行します。

   # update-ca-trust

手順

1. oscap コマンドに --remediate オプションを指定して使用します。

   $ sudo oscap xccdf eval --profile hipaa --remediate /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

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

検証

1. システムの OSPP プロファイルへのコンプライアンスを評価し、スキャン結果を ospp_report.html ファイルに保存します。

   $ oscap xccdf eval --report hipaa_report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

手順

1. Ansible を使用して OSPP に合わせてシステムを修正します。

   # ansible-playbook -i localhost, -c local /usr/share/scap-security-guide/ansible/rhel8-playbook-hipaa.yml

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

検証

1. システムの OSPP プロファイルへのコンプライアンスを評価し、スキャン結果を ospp_report.html ファイルに保存します。

   # oscap xccdf eval --profile hipaa --report hipaa_report.html /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

手順

1. システムをスキャンして結果を保存します。

   # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

2. 前の手順で生成されたファイルに基づいて Ansible Playbook を生成します。

   # oscap xccdf generate fix --fix-type ansible --output hipaa-remediations.yml hipaa-results.xml

3. hippa-remediations.yml ファイルには、手順 1 で実行されたスキャン中に失敗したルールの Ansible 修復が含まれています。この生成されたファイルを確認した後、ansible-playbook hipaa-remediations.yml コマンドで適用できます。

検証

1. お使いのテキストエディターで、手順 1 で実行したスキャンで失敗したルールが hipaa-remediations.yml ファイルに含まれていることを確認します。

手順

1. oscap コマンドを使用してシステムをスキャンし、結果を XML ファイルに保存します。以下の例では、oscap は hipaa プロファイルに対してシステムを評価します。

   # oscap xccdf eval --profile hipaa --results hipaa-results.xml /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

2. 前の手順で生成された結果ファイルに基づいて Bash スクリプトを生成します。

   # oscap xccdf generate fix --profile hipaa --fix-type bash --output hipaa-remediations.sh hipaa-results.xml

3. hippa-dss-remediations.sh ファイルには、手順 1 で実行されたスキャン中に失敗したルールの修復が含まれます。この生成されたファイルを確認したら、このファイルと同じディレクトリー内で ./hipaa-remediations.sh コマンドを使用して適用できます。

検証

1. お使いのテキストエディターで、手順 1 で実行したスキャンで失敗したルールが hipaa-remediations.sh ファイルに含まれていることを確認します。

手順

1. システムに最新 RHSA OVAL 定義をダウンロードします。

   # wget -O - https://www.redhat.com/security/data/oval/v2/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml

2. コンテナーまたはコンテナーイメージの ID を取得します。以下に例を示します。

   # podman images
   REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
   registry.access.redhat.com/ubi8/ubi   latest   096cae65a207   7 weeks ago   239 MB

3. コンテナーまたはコンテナーイメージで脆弱性をスキャンし、結果を vulnerability.html ファイルに保存します。

   # oscap-podman 096cae65a207 oval eval --report vulnerability.html rhel-8.oval.xml

   oscap-podman コマンドには root 権限が必要で、コンテナーの ID は最初の引数であることに注意してください。

検証

1. 結果をブラウザーで確認します。以下に例を示します。

   $ firefox vulnerability.html &

手順

1. コンテナーまたはコンテナーイメージの ID を取得します。以下に例を示します。

   # podman images
   REPOSITORY                            TAG      IMAGE ID       CREATED       SIZE
   registry.access.redhat.com/ubi8/ubi   latest   096cae65a207   7 weeks ago   239 MB

2. HIPAA プロファイルでコンテナーイメージのコンプライアンスを評価し、スキャン結果を report.html ファイルに保存します。

   # oscap-podman 096cae65a207 xccdf eval --report report.html --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

   OSPP または PCI-DSS ベースラインでセキュリティーコンプライアンスを評価する場合は、096cae65a207 をコンテナーイメージの ID に、hipaa の値を ospp または pci-dss に置き換えます。oscap-podman コマンドには、root 権限が必要なことに注意してください。

検証

1. 結果をブラウザーで確認します。以下に例を示します。

   $ firefox report.html &

手順

1. aide パッケージをインストールするには、次のコマンドを実行します。

   # yum install aide

2. 初期データベースを生成するには、次のコマンドを実行します。

   # aide --init

   注記

   デフォルト設定では、aide --init コマンドは、/etc/aide.conf ファイルで定義するディレクトリーとファイルのセットのみを確認します。ディレクトリーまたはファイルを AIDE データベースに追加し、監視パラメーターを変更するには、/etc/aide.conf を変更します。

3. データベースの使用を開始するには、初期データベースのファイル名から末尾の .new を削除します。

   # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

4. AIDE データベースの場所を変更するには、/etc/aide.conf ファイルを編集して、DBDIR 値を変更します。追加のセキュリティーのデータベース、設定、/usr/sbin/aide バイナリーファイルを、読み取り専用メディアなどの安全な場所に保存します。

手順

1. 手動でチェックを開始するには、以下を行います。

   # aide --check
   Start timestamp: 2018-07-11 12:41:20 +0200 (AIDE 0.16)
   AIDE found differences between database and filesystem!!
   ...
   [trimmed for clarity]

2. 最低でも、AIDE は週ごとに実行するようにシステムを設定します。最適な設定としては、AIDE を毎日実行します。たとえば、AIDE を毎日午前 04:05 に実行するようにスケジュールするには、cron コマンドを使用して、次の行を /etc/crontab ファイルを追加します。

    05 4 * * * root /usr/sbin/aide --check

手順

1. 基本となる AIDE データベースを更新します。

   # aide --update

   aide --update コマンドは、/var/lib/aide/aide.db.new.gz データベースファイルを作成します。

2. 整合性チェックで更新したデータベースを使用するには、ファイル名から末尾の .new を削除します。

手順

1. 暗号化するデバイスにあるファイルシステムのマウントをすべて解除します。以下に例を示します。

   # umount /dev/sdb1

2. LUKS ヘッダーを保存するための空き容量を確認します。以下のいずれかのオプションを選択します。

   • 論理ボリュームを暗号化する場合は、以下のように、ファイルシステムのサイズを変更せずに、論理ボリュームを拡張できます。以下に例を示します。

     # lvextend -L+32M vg00/lv00

   • parted などのパーティション管理ツールを使用してパーティションを拡張します。
   • このデバイスのファイルシステムを縮小します。ext2、ext3、または ext4 のファイルシステムには resize2fs ユーティリティーを使用できます。XFS ファイルシステムは縮小できないことに注意してください。

3. 暗号化を初期化します。以下に例を示します。

   # cryptsetup reencrypt \ --encrypt \ --init-only \ --reduce-device-size 32M \ /dev/sdb1 sdb1_encrypted

   このコマンドを実行するとパスフレーズの入力が求められ、暗号化プロセスが開始します。

4. デバイスをマウントします。

   # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted

5. オンライン暗号化を開始します。

   # cryptsetup reencrypt --resume-only /dev/sdb1

手順

1. プールにあるファイルシステムのマウントをすべて解除します。以下に例を示します。

   # umount /dev/sdb1

2. 暗号化を初期化します。

   # cryptsetup reencrypt \ --encrypt \ --init-only \ --header /path/to/header \ /dev/sdb1 sdb1_encrypted

   /path/to/header を、独立した LUKS ヘッダーのあるファイルへのパスに置き換えます。暗号化したデバイスを後でアンロックできるように、接続解除した LUKS ヘッダーにアクセスできる必要があります。

   このコマンドを実行するとパスフレーズの入力が求められ、暗号化プロセスが開始します。

3. デバイスをマウントします。

   # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted

4. オンライン暗号化を開始します。

   # cryptsetup reencrypt --resume-only --header /path/to/header /dev/sdb1

手順

1. 暗号化した LUKS パーティションとしてパーティションを設定します。

   # cryptsetup luksFormat /dev/sdb1

2. 暗号化した LUKS パーティションを開きます。

   # cryptsetup open /dev/sdb1 sdb1_encrypted

   これにより、パーティションのロックが解除され、デバイスマッパーを使用して新しいデバイスにマッピングされます。これは、 デバイス が暗号化されたデバイスであり、暗号化されたデータを上書きしないように /dev/mapper/device_mapped_name を使用して LUKS を通じてアドレス指定する必要があることをカーネルに警告します。

3. パーティションに暗号化されたデータを書き込むには、デバイスをマッピングした名前でアクセスする必要があります。これを実行するには、ファイルシステムを作成する必要があります。以下に例を示します。

   # mkfs -t ext4 /dev/mapper/sdb1_encrypted

4. デバイスをマウントします。

   # mount /dev/mapper/sdb1_encrypted mount-point

手順

1. 以下の内容を含む新しい playbook.yml ファイルを作成します。

   - hosts: all
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
            - sdb
           fs_type: xfs
           fs_label: label-name
           mount_point: /mnt/data
           encryption: true
           encryption_password: your-password
     roles:
      - rhel-system-roles.storage

2. オプション: Playbook の構文を確認します。

   # ansible-playbook --syntax-check playbook.yml

3. インベントリーファイルで Playbook を実行します。

   # ansible-playbook -i inventory.file /path/to/file/playbook.yml

手順

1. 暗号化されたボリュームを持つシステムに Clevis とそのピンをインストールするには、次のコマンドを実行します。

   # yum install clevis

2. データを複号するには、clevis decrypt コマンドを実行して、JWE (JSON Web Encryption) 形式で暗号文を指定します。以下に例を示します。

   $ clevis decrypt < secret.jwe

手順

1. tang パッケージとその依存関係をインストールするには、root で以下のコマンドを実行します。

   # yum install tang

2. 7500/tcp などの不要なポートを選択し、tangd サービスがそのポートにバインドできるようにします。

   # semanage port -a -t tangd_port_t -p tcp 7500

   ポートは 1 つのサービスのみで一度に使用できるため、すでに使用しているポートを使用しようとすると、ValueError: Port already defined エラーが発生します。

3. ファイアウォールのポートを開きます。

   # firewall-cmd --add-port=7500/tcp
   # firewall-cmd --runtime-to-permanent

4. tangd サービスを有効にします。

   # systemctl enable tangd.socket

5. オーバーライドファイルを作成します。

   # systemctl edit tangd.socket

6. 以下のエディター画面で、/etc/systemd/system/tangd.socket.d/ ディレクトリーにある空の override.conf ファイルを開き、次の行を追加して、Tang サーバーのデフォルトのポートを、80 から、以前取得した番号に変更します。

   [Socket]
   ListenStream=
   ListenStream=7500

   ファイルを保存して、エディターを終了します。

7. 変更した設定を再読み込みします。

   # systemctl daemon-reload

8. 設定が機能していることを確認します。

   # systemctl show tangd.socket -p Listen
   Listen=[::]:7500 (Stream)

9. tangd サービスを開始します。

   # systemctl start tangd.socket

   tangd が、systemd のソケットアクティベーションメカニズムを使用しているため、最初に接続するとすぐにサーバーが起動します。最初の起動時に、一組の暗号鍵が自動的に生成されます。鍵の手動生成などの暗号化操作を実行するには、jose ユーティリティーを使用します。

手順

1. /var/db/tang 鍵データベースディレクトリーのすべての鍵の名前の前に . を指定して、アドバタイズメントに対して非表示にします。以下の例のファイル名は、Tang サーバーの鍵データベースディレクトリーにある一意のファイル名とは異なります。

   # cd /var/db/tang
   # ls -l
   -rw-r--r--. 1 root root 349 Feb  7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
   -rw-r--r--. 1 root root 354 Feb  7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
   # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG3KbJmdiR020hY.jwk
   # mv y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk .y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk

2. 名前が変更され、Tang サーバーのアドバタイズに対してすべての鍵が非表示になっていることを確認します。

   # ls -l
   total 0

3. Tang サーバーの /var/db/tang で /usr/libexec/tangd-keygen コマンドを使用して新しい鍵を生成します。

   # /usr/libexec/tangd-keygen /var/db/tang
   # ls /var/db/tang
   3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk zyLuX6hijUy_PSeUEFDi7hi38.jwk

4. Tang サーバーが、以下のように新規キーペアから署名キーを公開していることを確認します。

   # tang-show-keys 7500
   3ZWS6-cDrCG61UPJS2BMmPU4I54

5. NBDE クライアントで clevis luks report コマンドを使用して、Tang サーバーでアドバタイズされた鍵が同じままかどうかを確認します。clevis luks list コマンドを使用すると、関連するバインディングのあるスロットを特定できます。以下に例を示します。

   # clevis luks list -d /dev/sda2
   1: tang '{"url":"http://tang.srv"}'
   # clevis luks report -d /dev/sda2 -s 1
   ...
   Report detected that some keys were rotated.
   Do you want to regenerate luks metadata with "clevis luks regen -d /dev/sda2 -s 1"? [ynYN]

6. 新しい鍵の LUKS メタデータを再生成するには、直前のコマンドプロンプトで y を押すか、clevis luks regen コマンドを使用します。

   # clevis luks regen -d /dev/sda2 -s 1

7. すべての古いクライアントが新しい鍵を使用することを確認したら、Tang サーバーから古い鍵を削除できます。次に例を示します。

   # cd /var/db/tang
   # rm .*.jwk

手順

1. Web ブラウザーに以下のアドレスを入力して、RHEL Web コンソールを開きます。

   https://localhost:9090

   リモートシステムに接続する際に、localhost の部分をリモートサーバーのホスト名または IP アドレスに置き換えます。

2. 認証情報を指定して、ストレージ をクリックします。暗号化したデバイスを選択し、コンテンツ で 暗号化 をクリックします。

3. Keys セクションの + をクリックして Tang キーを追加します。

   

4. Tang サーバーのアドレスと、LUKS で暗号化したデバイスのロックを解除するパスワードを指定します。Add をクリックして確定します。

   

5. 以下のダイアログウインドウは、鍵ハッシュが一致することを確認するコマンドを提供します。RHEL 8.2 では、tang-show-keys スクリプトが導入され、ポート 7500 で実行している Tang サーバーで以下のコマンドを使用して鍵ハッシュを取得できます。

   # tang-show-keys 7500
   3ZWS6-cDrCG61UPJS2BMmPU4I54

   RHEL 8.1 以前では、以下のコマンドを使用して鍵ハッシュを取得します。

   # curl -s localhost:7500/adv | jose fmt -j- -g payload -y -o- | jose jwk use -i- -r -u verify -o- | jose jwk thp -i-
   3ZWS6-cDrCG61UPJS2BMmPU4I54

6. Web コンソールと前述のコマンドの出力のキーハッシュが同じ場合は、Trust key をクリックします。

   

7. 初期ブートシステムでディスクバインディングを処理できるようにするには、左側のナビゲーションバーの下部にある Terminal をクリックし、次のコマンドを入力します。

   # yum install clevis-dracut
   # dracut -fv --regenerate-all

検証

1. 新規に追加された Tang キーが Keyserver タイプの Keys セクションに一覧表示されていることを確認します。

   

2. バインディングが初期ブートで使用できることを確認します。次に例を示します。

   # lsinitrd | grep clevis
   clevis
   clevis-pin-sss
   clevis-pin-tang
   clevis-pin-tpm2
   -rwxr-xr-x   1 root     root         1600 Feb 11 16:30 usr/bin/clevis
   -rwxr-xr-x   1 root     root         1654 Feb 11 16:30 usr/bin/clevis-decrypt
   ...
   -rwxr-xr-x   2 root     root           45 Feb 11 16:30 usr/lib/dracut/hooks/initqueue/settled/60-clevis-hook.sh
   -rwxr-xr-x   1 root     root         2257 Feb 11 16:30 usr/libexec/clevis-luks-askpass

手順

1. Clevis 暗号化クライアントを Tang サーバーにバインドするには、clevis encrypt tang サブコマンドを使用します。

   $ clevis encrypt tang '{"url":"http://tang.srv:port"}' < input-plain.txt > secret.jwe
   The advertisement contains the following signing keys:
   
   _OsIk0T-E2l6qjfdDiwVmidoZjA
   
   Do you wish to trust these keys? [ynYN] y

   この例の URL (http://tang.srv:port) を、 tang がインストールされているサーバーの URL に変更します。secret.jwe 出力ファイルには、JSON Web の暗号形式で暗号化した暗号文が含まれます。この暗号文は input-plain.txt 入力ファイルから読み込まれます。

   また、構成に SSH アクセスなしで Tang サーバーとの非対話型の通信が必要な場合は、アドバタイズメントをダウンロードしてファイルに保存できます。

   $ curl -sfg http://tang.srv:port/adv -o adv.jws

   ファイルやメッセージの暗号化など、次のタスクには adv.jws ファイルのアドバタイズメントを使用します。

   $ echo 'hello' | clevis encrypt tang '{"url":"http://tang.srv:port","adv":"adv.jws"}'

2. データを複号するには、clevis decrypt コマンドを実行して、暗号文 (JWE) を提供します。

   $ clevis decrypt < secret.jwe > output-plain.txt

手順

1. /dev/sda2 などのボリュームがどの LUKS バージョンであるかを確認し、Clevis にバインドされているスロットおよびトークンを特定します。

   # cryptsetup luksDump /dev/sda2
   LUKS header information
   Version:        2
   ...
   Keyslots:
     0: luks2
   ...
   1: luks2
         Key:        512 bits
         Priority:   normal
         Cipher:     aes-xts-plain64
   ...
         Tokens:
           0: clevis
                 Keyslot:  1
   ...

   上記の例では、Clevis トークンは 0 で識別され、関連付けられた鍵スロットは 1 です。

2. LUKS2 暗号化の場合は、トークンを削除します。

   # cryptsetup token remove --token-id 0 /dev/sda2

3. デバイスを LUKS1 で暗号化し、cryptsetup luksDump コマンドの出力に Version: 1 文字列が示されている場合は、luksmeta wipe コマンドでこの追加手順を行います。

   # luksmeta wipe -d /dev/sda2 -s 1

4. Clevis パスフレーズを含む鍵スロットを削除します。

   # cryptsetup luksKillSlot /dev/sda2 1

手順

1. TPM 2.0 チップを使用して暗号化するクライアントをデプロイするには、JSON 設定オブジェクト形式の引数のみが使用されている clevis encrypt tpm2 サブコマンドを使用します。

   $ clevis encrypt tpm2 '{}' < input-plain.txt > secret.jwe

   別の階層、ハッシュ、および鍵アルゴリズムを選択するには、以下のように、設定プロパティーを指定します。

   $ clevis encrypt tpm2 '{"hash":"sha1","key":"rsa"}' < input-plain.txt > secret.jwe

2. データを復号するには、JSON Web Encryption (JWE) 形式の暗号文を提供します。

   $ clevis decrypt < secret.jwe > output-plain.txt

手順

1. LUKS で暗号化した既存のボリュームを自動的にアンロックするには、サブパッケージの clevis-luks をインストールします。

   # yum install clevis-luks

2. PBD 用 LUKS 暗号化ボリュームを特定します。次の例では、ブロックデバイスは /dev/sda2 と呼ばれています。

   # lsblk
   NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda                                             8:0    0    12G  0 disk
   ├─sda1                                          8:1    0     1G  0 part  /boot
   └─sda2                                          8:2    0    11G  0 part
     └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0    0    11G  0 crypt
       ├─rhel-root                               253:0    0   9.8G  0 lvm   /
       └─rhel-swap                               253:1    0   1.2G  0 lvm   [SWAP]

3. clevis luks bind コマンドを使用して、ボリュームを Tang サーバーにバインドします。

   # clevis luks bind -d /dev/sda2 tang '{"url":"http://tang.srv"}'
   The advertisement contains the following signing keys:
   
   _OsIk0T-E2l6qjfdDiwVmidoZjA
   
   Do you wish to trust these keys? [ynYN] y
   You are about to initialize a LUKS device for metadata storage.
   Attempting to initialize it may result in data loss if data was
   already written into the LUKS header gap in a different format.
   A backup is advised before initialization is performed.
   
   Do you wish to initialize /dev/sda2? [yn] y
   Enter existing LUKS password:

   このコマンドは、以下の 4 つの手順を実行します。

   1. LUKS マスター鍵と同じエントロピーを使用して、新しい鍵を作成します。
   2. Clevis で新しい鍵を暗号化します。
   3. LUKS2 ヘッダートークンに Clevis JWE オブジェクトを保存するか、デフォルト以外の LUKS1 ヘッダーが使用されている場合は LUKSMeta を使用します。

   4. LUKS を使用する新しい鍵を有効にします。

      注記

      バインド手順では、空き LUKS パスワードスロットが少なくとも 1 つあることが前提となっています。そのスロットの 1 つを clevis luks bind コマンドが使用します。

4. ボリュームは、現在、既存のパスワードと Clevis ポリシーを使用してロックを解除できます。

5. システムの起動プロセスの初期段階でディスクバインディングを処理するようにするには、インストール済みのシステムで dracut ツールを使用します。

   # yum install clevis-dracut

   Red Hat Enterprise Linux 8 では、Clevis はホスト固有の設定オプションを指定せずに汎用 initrd (initial ramdisk) を生成し、カーネルコマンドラインに rd.neednet=1 などのパラメーターを自動的に追加しません。初期の起動時にネットワークを必要とする Tang ピンを使用する場合は、--hostonly-cmdline 引数を使用し、dracut が Tang バインディングを検出すると rd.neednet=1 を追加します。

   # dracut -fv --regenerate-all --hostonly-cmdline

   または、/etc/dracut.conf.d/ に .conf ファイルを作成し、以下のように hostonly_cmdline=yes オプションを追加します。

   # echo "hostonly_cmdline=yes" > /etc/dracut.conf.d/clevis.conf

   次に、--hostonly-cmdline なしで dracut を使用できます。

   # dracut -fv --regenerate-all

検証

1. Clevis JWE オブジェクトが LUKS ヘッダーに適切に置かれていることを確認するには、clevis luks list コマンドを使用します。

   # clevis luks list -d /dev/sda2
   1: tang '{"url":"http://tang.srv:port"}'

手順

1. 一時パスワードを使用して、LUKS 暗号化が有効になっているディスクを、/boot 以外のすべてのマウントポイントで分割するように、キックスタートに指示します。パスワードは、登録プロセスの手順に使用するための一時的なものです。

   part /boot --fstype="xfs" --ondisk=vda --size=256
   part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass

   OSPP 準拠のシステムには、より複雑な構成が必要であることに注意してください。次に例を示します。

   part /boot --fstype="xfs" --ondisk=vda --size=256
   part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass
   part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass
   part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass
   part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass

2. 関連する Clevis パッケージを %packages セクションに追加して、インストールします。

   %packages
   clevis-dracut
   %end

3. clevis luks bind を呼び出して、%post セクションのバインディングを実行します。その後、一時パスワードを削除します。

   %post
   curl -sfg http://tang.srv/adv -o adv.jws
   clevis luks bind -f -k- -d /dev/vda2 \
   tang '{"url":"http://tang.srv","adv":"adv.jws"}' \ <<< "temppass"
   cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
   %end

   前述の例では、バインディング設定の一部として Tang サーバーからアドバタイズメントをダウンロードし、バインディングを完全に非対話型にします。

   警告

   cryptsetup luksRemoveKey コマンドは、それを適用する LUKS2 デバイスがそれ以上に管理されるのを防ぎます。LUKS1 デバイスに対してのみ dmsetup コマンドを使用して、削除されたマスターキーを回復できます。

手順

1. USB ドライブなど、LUKS で暗号化したリムーバブルストレージデバイスを自動的にアンロックするには、clevis-udisks2 パッケージをインストールします。

   # yum install clevis-udisks2

2. システムを再起動し、「LUKS で暗号化したボリュームの手動登録の設定」に従って、clevis luks bind コマンドを使用したバインディング手順を実行します。以下に例を示します。

   # clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'

3. LUKS で暗号化したリムーバブルデバイスは、GNOME デスクトップセッションで自動的にアンロックできるようになりました。Clevis ポリシーにバインドするデバイスは、clevis luks unlock コマンドでアンロックできます。

   # clevis luks unlock -d /dev/sdb1

手順

1. registry.redhat.io レジストリー から rhel8-tang コンテナーイメージをプルします。

   # podman pull registry.redhat.io/rhel8/rhel8-tang

2. コンテナーを実行し、そのポートを指定して Tang 鍵へのパスを指定します。上記の例では、rhel8-tang コンテナーを実行し、ポート 7500 を指定し、/var/db/tang ディレクトリーの Tang 鍵へのパスを示します。

   # podman run -d -p 7500:_7500_ -v tang-keys:/var/db/tang --name tang registry.redhat.io/rhel8/rhel8-tang

   Tang はデフォルトでポート 80 を使用しますが、Apache HTTP サーバーなどの他のサービスと共存する可能性があることに注意してください。

3. (必要に応じて) セキュリティーを強化する場合は、Tang 鍵を定期的にローテーションします。tangd-rotate-keys スクリプトを使用できます。以下に例を示します。

   # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel8/rhel8-tang tangd-rotate-keys -v -d /var/db/tang
   Rotated key 'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk' -> .'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk'
   Rotated key 'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk' -> .'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk'
   Created new key GrMMX_WfdqomIU_4RyjpcdlXb0E.jwk
   Created new key _dTTfn17sZZqVAp80u3ygFDHtjk.jwk
   Keys rotated successfully.

手順

1. RHEL Ansible リポジトリーを有効にします。以下に例を示します。

   # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms

2. Ansible Engine をインストールします。

   # yum install ansible

3. RHEL システムロールをインストールします。

   # yum install rhel-system-roles

4. Tang サーバーの設定が含まれる Playbook を準備します。ゼロから開始するか、または /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ ディレクトリーにある Playbook のいずれかのサンプルを使用することができます。

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml

5. 選択したテキストエディターで Playbook を編集します。以下に例を示します。

   # vi my-tang-playbook.yml

6. 必要なパラメーターを追加します。以下の Playbook の例では、Tang サーバーのデプロイとキーローテーションを確実に実行します。

   ---
   - hosts: all
   
     vars:
       nbde_server_rotate_keys: yes
   
     roles:
       - linux-system-roles.nbde_server

7. 終了した Playbook を適用します。

   # ansible-playbook -i host1,host2,host3 my-tang-playbook.yml

手順

1. RHEL Ansible リポジトリーを有効にします。以下に例を示します。

   # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms

2. Ansible Engine をインストールします。

   # yum install ansible

3. RHEL システムロールをインストールします。

   # yum install rhel-system-roles

4. Clevis クライアントの設定が含まれる Playbook を準備します。ゼロから開始するか、または /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/ ディレクトリーにある Playbook のいずれかのサンプルを使用することができます。

   # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml

5. 選択したテキストエディターで Playbook を編集します。以下に例を示します。

   # vi my-clevis-playbook.yml

6. 必要なパラメーターを追加します。以下の Playbook の例では、2 つの Tang サーバーのうち少なくとも 1 台が利用可能な場合に、LUKS で暗号化した 2 つのボリュームを自動的にアンロックするように Clevis クライアントを設定します。

   ---
   - hosts: all
   
     vars:
       nbde_client_bindings:
         - device: /dev/rhel/root
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
         - device: /dev/rhel/swap
           encryption_key_src: /etc/luks/keyfile
           servers:
             - http://server1.example.com
             - http://server2.example.com
   
     roles:
       - linux-system-roles.nbde_client

7. 終了した Playbook を適用します。

   # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml

ファイルシステムのルールの例

1. すべての書き込みアクセスと /etc/passwd ファイルのすべての属性変更をログに記録するルールを定義するには、次のコマンドを実行します。

   # auditctl -w /etc/passwd -p wa -k passwd_changes

2. すべての書き込みアクセスと、/etc/selinux/ ディレクトリー内の全ファイルへのアクセスと、その属性変更をすべてログに記録するルールを定義するには、次のコマンドを実行します。

   # auditctl -w /etc/selinux/ -p wa -k selinux_changes

システムロールのルールの例

1. システムで 64 ビットアーキテクチャーが使用され、システムコールの adjtimex または settimeofday がプログラムにより使用されるたびにログエントリーを作成するルールを定義するには、次のコマンドを実行します。

   # auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change

2. ユーザー ID が 1000 以上のシステムユーザーがファイルを削除したりファイル名を変更するたびに、ログエントリーを作成するルールを定義するには、次のコマンドを実行します。

   # auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k delete

   -F auid!=4294967295 オプションが、ログイン UID が設定されていないユーザーを除外するために使用されています。

手順

1. /usr/lib/systemd/system/auditd.service ファイルを /etc/systemd/system/ ディレクトリーにコピーします。

   # cp -f /usr/lib/systemd/system/auditd.service /etc/systemd/system/

2. 任意のテキストエディターで /etc/systemd/system/auditd.service ファイルを編集します。以下に例を示します。

   # vi /etc/systemd/system/auditd.service

3. augenrules を含む行をコメントアウトし、auditctl -R コマンドを含む行のコメント設定を解除します。

   #ExecStartPost=-/sbin/augenrules --load
   ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules

4. systemd デーモンを再読み込みして、auditd.service ファイルの変更を取得します。

   # systemctl daemon-reload

5. auditd サービスを再起動します。

   # service auditd restart

手順

1. fapolicyd パッケージをインストールします。

   # yum install fapolicyd

2. fapolicyd サービスを有効にして開始します。

   # systemctl enable --now fapolicyd

検証

1. fapolicydサービスが正しく実行されていることを確認します。

   # systemctl status fapolicyd
   ● fapolicyd.service - File Access Policy Daemon
      Loaded: loaded (/usr/lib/systemd/system/fapolicyd.service; enabled; vendor p>
      Active: active (running) since Tue 2019-10-15 18:02:35 CEST; 55s ago
     Process: 8818 ExecStart=/usr/sbin/fapolicyd (code=exited, status=0/SUCCESS)
    Main PID: 8819 (fapolicyd)
       Tasks: 4 (limit: 11500)
      Memory: 78.2M
      CGroup: /system.slice/fapolicyd.service
              └─8819 /usr/sbin/fapolicyd
   
   Oct 15 18:02:35 localhost.localdomain systemd[1]: Starting File Access Policy D>
   Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Initialization of the da>
   Oct 15 18:02:35 localhost.localdomain fapolicyd[8819]: Reading RPMDB into memory
   Oct 15 18:02:35 localhost.localdomain systemd[1]: Started File Access Policy Da>
   Oct 15 18:02:36 localhost.localdomain fapolicyd[8819]: Creating database

2. root 権限のないユーザーとしてログインし、以下のように fapolicyd が機能していることを確認します。

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

手順

1. カスタムバイナリーを必要なディレクトリにコピーします。以下に例を示します。

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

2. カスタムバイナリーに trusted のマークを付けます。

   # fapolicyd-cli --file add /tmp/ls

   上記のコマンドは、対応する行を /etc/fapolicyd/fapolicyd.trust に追加します。

3. fapolicyd データベースを更新します。

   # fapolicyd-cli --update

4. fapolicyd を再起動します。

   # systemctl restart fapolicyd

検証

1. たとえば、カスタムバイナリーが実行できることを確認します。

   $ /tmp/ls
   ls

手順

1. カスタムバイナリーを必要なディレクトリにコピーします。以下に例を示します。

   $ cp /bin/ls /tmp
   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

2. fapolicyd サービスを停止します。

   # systemctl stop fapolicyd

3. デバッグモードを使用して、対応するルールを識別します。fapolicyd --debug コマンドの出力は冗長で、Ctrl+C を押すか、対応するプロセスを強制終了するだけで停止できるため、エラー出力をファイルにリダイレクトします。

   # fapolicyd --debug 2> fapolicy.output &
   [1] 51341

   または、別の端末で fapolicyd デバッグモードを実行できます。

4. 許可されなかったコマンドを繰り返します。

   $ /tmp/ls
   bash: /tmp/ls: Operation not permitted

5. デバッグモードをフォアグラウンドで再開し、Ctrl+C を押して停止します。

   # fg
   fapolicyd --debug
   ^Cshutting down...
   Inter-thread max queue depth 1
   Allowed accesses: 2
   Denied accesses: 1
   [...]

   または、fapolicyd デバッグモードのプロセスを強制終了します。

   # kill 51341

6. アプリケーションの実行を拒否するルールを見つけます。

   # cat fapolicy.output
   [...]
   rule:9 dec=deny_audit perm=execute auid=1000 pid=51362 exe=/usr/bin/bash : file=/tmp/ls ftype=application/x-executable
   [...]

7. /etc/fapolicyd/fapolicyd.rules ファイルで、カスタムバイナリーの実行を拒否したルールの 前に 新しい allow ルールを追加します。上記のコマンドの出力では、この例に含まれるルールがルール番号 9 であることを示しています。

   allow perm=execute exe=/usr/bin/bash trust=1 : path=/tmp/ls ftype=application/x-executable trust=0

   または、/etc/fapolicyd/fapolicyd.rules ファイルに次のルールを追加することにより、/tmp ディレクトリー内のすべてのバイナリーの実行を許可できます。

   allow perm=execute exe=/usr/bin/bash trust=1 : dir=/tmp/ all trust=0

8. カスタムバイナリーのコンテンツの変更を防ぐには、SHA-256 チェックサムを使用して必要なルールを定義します。

   $ sha256sum /tmp/ls
   780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836  ls

   ルールを以下の定義に変更します。

   allow perm=execute exe=/usr/bin/bash trust=1 : sha256hash=780b75c90b2d41ea41679fcb358c892b1251b68d1927c80fbc0d9d148b25e836

9. fapolicyd サービスを開始します。

   # systemctl start fapolicyd

検証

1. たとえば、カスタムバイナリーが実行できることを確認します。

   $ /tmp/ls
   ls

手順

1. 任意のテキストエディターで /etc/fapolicyd/fapolicyd.conf ファイルを開きます。以下に例を示します。

   # vi /etc/fapolicyd/fapolicyd.conf

2. 整合性 オプションの値を none から sha256 に変更し、ファイルを保存してエディターを終了します。

   integrity = sha256

3. fapolicyd サービスを再起動します。

   # systemctl restart fapolicyd

検証

1. 検証に使用するファイルのバックアップを作成します。

   # cp /bin/more /bin/more.bak

2. /bin/more バイナリーの内容を変更します。

   # cat /bin/less > /bin/more

3. 変更したバイナリーを一般ユーザーとして使用します。

   # su example.user
   $ /bin/more /etc/redhat-release
   bash: /bin/more: Operation not permitted

4. 変更を元に戻します。

   # mv -f /bin/more.bak /bin/more

手順

1. usbguard パッケージをインストールします。

   # yum install usbguard

2. 初期ルールセットを作成します。

   # usbguard generate-policy > /etc/usbguard/rules.conf

3. usbguard デーモンを起動し、システムの起動時に自動的に起動することを確認します。

   # systemctl enable --now usbguard

検証

1. usbguard サービスが実行していることを確認します。

   # systemctl status usbguard
   ● usbguard.service - USBGuard daemon
      Loaded: loaded (/usr/lib/systemd/system/usbguard.service; enabled; vendor preset: disabled)
      Active: active (running) since Thu 2019-11-07 09:44:07 CET; 3min 16s ago
        Docs: man:usbguard-daemon(8)
    Main PID: 6122 (usbguard-daemon)
       Tasks: 3 (limit: 11493)
      Memory: 1.2M
      CGroup: /system.slice/usbguard.service
              └─6122 /usr/sbin/usbguard-daemon -f -s -c /etc/usbguard/usbguard-daemon.conf
   
   Nov 07 09:44:06 localhost.localdomain systemd[1]: Starting USBGuard daemon...
   Nov 07 09:44:07 localhost.localdomain systemd[1]: Started USBGuard daemon.

2. USBGuard が認識する USB デバイスの一覧を表示します。

   # usbguard list-devices
   4: allow id 1d6b:0002 serial "0000:02:00.0" name "xHCI Host Controller" hash...

手順

1. USBGuard が認識する USB デバイスの一覧を表示します。

   # usbguard list-devices
   1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
   ...
   6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50

2. デバイス 6 を認証してシステムと対話します。

   # usbguard allow-device 6

3. デバイス 6 の認証を解除し、削除します。

   # usbguard reject-device 6

4. デバイス 6 の認可を解除し、保持します。

   # usbguard block-device 6

手順

1. usbguard デーモンがルールの書き込みを許可するように SELinux を設定します。

   1. usbguard に関連する semanage ブール値を表示します。

      # semanage boolean -l | grep usbguard
      usbguard_daemon_write_conf     (off  ,  off)  Allow usbguard to daemon write conf
      usbguard_daemon_write_rules    (on   ,   on)  Allow usbguard to daemon write rules

   2. 必要に応じて、usbguard_daemon_write_rules のブール値が無効になっている場合は、有効にします。

      # semanage boolean -m --on usbguard_daemon_write_rules

2. USBGuard が認識する USB デバイスの一覧を表示します。

   # usbguard list-devices
   1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00
   ...
   6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50

3. デバイス 6 を永続的に認証してシステムと対話します。

   # usbguard allow-device 6 -p

4. デバイス 6 を永続的に認証し、削除します。

   # usbguard reject-device 6 -p

5. デバイス 6 を永続的に承認し、保持します。

   # usbguard block-device 6 -p

検証

1. USBGuard ルールに変更が含まれていることを確認します。

   # usbguard list-rules

手順

1. 現在接続している USB デバイスを認証するポリシーを作成し、生成されたルールを rules.conf ファイルに保存します。

   # usbguard generate-policy --no-hashes > ./rules.conf

   --no-hashes オプションは、デバイスのハッシュ属性を生成しません。構成設定のハッシュ属性は永続的ではない可能性があるため、回避してください。

2. 選択したテキストエディターで rules.conf ファイルを編集します。次に例を示します。

   # vi ./rules.conf

3. 必要に応じて、ルールを追加、削除、または編集します。たとえば、以下のルールを使用すると、大容量ストレージインターフェースが 1 つあるデバイスのみがシステムと対話できます。

   allow with-interface equals { 08:*:* }

   詳細なルール言語の説明とその他の例は、man ページの usbguard-rules.conf(5) を参照してください。

4. 更新したポリシーをインストールします。

   # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf

5. usbguard デーモンを再起動して、変更を適用します。

   # systemctl restart usbguard

検証

1. カスタムルールがアクティブポリシーにあることを確認します。以下に例を示します。

   # usbguard list-rules
   ...
   4: allow with-interface 08:*:*
   ...

手順

1. 現在接続している USB デバイスを認証するポリシーを作成し、生成されたルールを、新しい .conf ファイル (例えば policy.conf) ファイルに保存します。

   # usbguard generate-policy --no-hashes > ./policy.conf

   --no-hashes オプションは、デバイスのハッシュ属性を生成しません。構成設定のハッシュ属性は永続的ではない可能性があるため、回避してください。

2. 任意のテキストエディターで rules.conf ファイルを編集します。次に例を示します。

   # vi ./policy.conf
   ...
   allow id 04f2:0833 serial "" name "USB Keyboard" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
   ...

3. 選択した行を別を別の .conf ファイルに移動します。

   注記

   ファイル名の先頭にある 2 つの数字は、デーモンが設定ファイルを読み込む順序を指定します。

   たとえば、キーボードのルールを新規 .conf ファイルにコピーします。

   # grep "USB Keyboard" ./policy.conf > ./10keyboards.conf

4. 新しいポリシーを /etc/usbguard/rules.d/ ディレクトリーにインストールします。

   # install -m 0600 -o root -g root 10keyboards.conf /etc/usbguard/rules.d/10keyboards.conf

5. 残りの行をメインの rules.conf ファイルに移動します。

   # grep -v "USB Keyboard" ./policy.conf > ./rules.conf

6. 残りのルールをインストールします。

   # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf

7. usbguard デーモンを再起動して、変更を適用します。

   # systemctl restart usbguard

検証

1. アクティブな USBGuard ルールをすべて表示します。

   # usbguard list-rules
   ...
   15: allow id 04f2:0833 serial "" name "USB Keyboard" hash "kxM/iddRe/WSCocgiuQlVs6Dn0VEza7KiHoDeTz0fyg=" parent-hash "2i6ZBJfTl5BakXF7Gba84/Cp1gslnNc1DM6vWQpie3s=" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown"
   ...

2. rules.conf ファイルと、/etc/usbguard/rules.d/ ディレクトリー内の .conf ファイルの内容をすべて表示します。

   # cat /etc/usbguard/rules.conf /etc/usbguard/rules.d/*.conf

3. アクティブなルールに、ファイルのすべてのルールが正しく、正しい順序で含まれていることを確認します。

手順

1. 任意のテキストエディターで /etc/usbguard/usbguard-daemon.conf ファイルを編集します。

   # vi /etc/usbguard/usbguard-daemon.conf

2. たとえば、wheel グループの全ユーザーが IPC インターフェースを使用できるように、ルールがある行を追加して、ファイルを保存します。

   IPCAllowGroups=wheel

3. usbguard コマンドで、ユーザーまたはグループを追加することもできます。たとえば、次のコマンドを使用すると、joesec ユーザーが Devices セクションおよび Exceptions セクションに完全アクセスできます。さらに、joesec は現在のポリシーの一覧を表示し、ポリシーシグナルをリッスンできます。

   # usbguard add-user joesec --devices ALL --policy list,listen --exceptions ALL

   joesec ユーザーに付与されたパーミッションを削除するには、usbguard remove-user joesec コマンドを使用します。

4. usbguard デーモンを再起動して、変更を適用します。

   # systemctl restart usbguard

手順

1. usbguard-daemon.conf ファイルを、選択したテキストエディターで編集します。

   # vi /etc/usbguard/usbguard-daemon.conf

2. AuditBackend オプションを、FileAudit から LinuxAudit に変更します。

   AuditBackend=LinuxAudit

3. usbguard デーモンを再起動して、設定変更を適用します。

   # systemctl restart usbguard

検証

1. 監査 デーモンログを USB 認証イベントに対してクエリーします。次に例を示します。

   # ausearch -ts recent -m USER_DEVICE