手順

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

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

手順

1. RHEL Web コンソールにログインします。詳細は、Web コンソールへのログイン を参照してください。
2. Overview ページの Configuration カードで、Crypto policy の横にある現在のポリシー値をクリックします。
3. Change crypto policy ダイアログウィンドウで、使用を開始するポリシーレベルをクリックします。
4. Apply and reboot ボタンをクリックします。

手順

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

   # fips-mode-setup --enable
   Kernel initramdisks are being regenerated. This might take some time.
   Setting system policy to FIPS
   Note: System-wide crypto policies are applied on application start-up.
   It is recommended to restart the system for the change of policies
   to fully take place.
   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 MYCRYPTO-1.pmod
   # touch SCOPES-AND-WILDCARDS.pmod

   重要

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

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

   # vi MYCRYPTO-1.pmod

   min_rsa_size = 3072
   hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512

   # vi SCOPES-AND-WILDCARDS.pmod

   # Disable the AES-128 cipher, all modes
   cipher = -AES-128-*
   
   # Disable CHACHA20-POLY1305 for the TLS protocol (OpenSSL, GnuTLS, NSS, and OpenJDK)
   cipher@TLS = -CHACHA20-POLY1305
   
   # Allow using the FFDHE-1024 group with the SSH protocol (libssh and OpenSSH)
   group@SSH = FFDHE-1024+
   
   # Disable all CBC mode ciphers for the SSH protocol (libssh and OpenSSH)
   cipher@SSH = -*-CBC
   
   # Allow the AES-256-CBC cipher in applications using libssh
   cipher@libssh = AES-256-CBC+

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

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

   # update-crypto-policies --set DEFAULT:MYCRYPTO-1:SCOPES-AND-WILDCARDS

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: rhel-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_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: rhel-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. /etc/polkit-1/rules.d/ ディレクトリーに新規ファイルを作成します。

   # touch /etc/polkit-1/rules.d/00-test.rules

2. 選択したエディターでファイルを編集します。以下に例を示します。

   # vi /etc/polkit-1/rules.d/00-test.rules

3. 以下の行を挿入します。

   polkit.addRule(function(action, subject) {
     if (action.id == "org.debian.pcsc-lite.access_pcsc" ||
     	action.id == "org.debian.pcsc-lite.access_card") {
   	polkit.log("action=" + action);
   	polkit.log("subject=" + subject);
     }
   });

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

4. pcscd サービスおよび polkit サービスを再起動します。

   # systemctl restart pcscd.service pcscd.socket polkit.service

検証

1. pcscd の認可リクエストを作成します。たとえば、Firefox の Web ブラウザーを開くか、opensc が提供する pkcs11-tool -L を使用します。

2. 拡張ログエントリーを表示します。以下に例を示します。

   # journalctl -u polkit --since "1 hour ago"
   polkitd[1224]: <no filename>:4: action=[Action id='org.debian.pcsc-lite.access_pcsc']
   polkitd[1224]: <no filename>:5: subject=[Subject pid=2020481 user=user' groups=user,wheel,mock,wireshark seat=null session=null local=true active=true]

手順

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

   # 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 --profile hipaa --output hipaa-remediations.yml hipaa-results.xml

3. hippa-remediations.yml ファイルには、手順 1 で実行されたスキャン中に失敗したルールの Ansible 修復が含まれています。この生成されたファイルを確認した後、ansible-playbook 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. システムに最新 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. コンテナーまたはコンテナーイメージの 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. 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. たとえば、81000001 の永続ハンドルを持つ SHA-256 プライマリーストレージキーを使用して 2048 ビット RSA を作成します。

   1. tss2 パッケージの使用:

      # TPM_DEVICE=/dev/tpm0 tsscreateprimary -hi o -st
      Handle 80000000
      # TPM_DEVICE=/dev/tpm0 tssevictcontrol -hi o -ho 80000000 -hp 81000001

   2. tpm2-tools パッケージの使用:

      # tpm2_createprimary --key-algorithm=rsa2048 --key-context=key.ctxt
      name-alg:
        value: sha256
        raw: 0xb
      …
      sym-keybits: 128
      rsa: xxxxxx…
      
      # tpm2_evictcontrol -c key.ctxt 0x81000001
      persistentHandle: 0x81000001
      action: persisted

2. keyctl add trusted <NAME> "new <KEY_LENGTH> keyhandle=<PERSISTENT-HANDLE> [options]" <KEYRING> の構文で TPM 2.0 を使用して、信頼できるキーを作成します。この例では、永続ハンドルは 81000001 です。

   # keyctl add trusted kmk "new 32 keyhandle=0x81000001" @u
   642500861

   このコマンドは、kmk という名前の信頼できる鍵を 32 バイト (256 ビット) の長さで作成し、ユーザーキーリング (@u) に配置します。鍵の長さは 32 から 128 バイト (256 から 1024 ビット) です。

3. カーネルキーリングの現在の構造を一覧表示します。

   # keyctl show
   Session Keyring
          -3 --alswrv    500   500  keyring: ses 97833714 --alswrv 500 -1 \ keyring: uid.1000 642500861 --alswrv 500 500 \ trusted: kmk

4. ユーザー空間のブロブに鍵をエクスポートします。

   # keyctl pipe 642500861 > kmk.blob

   このコマンドは、pipe サブコマンドと kmk のシリアル番号を使用します。

5. ユーザー空間のブロブから信頼できる鍵を読み込み、ブロブを引数として add サブコマンドを使用します。

   # keyctl add trusted kmk "load `cat kmk.blob`" @u
   268728824

6. keyctl add encrypted <NAME> "new [FORMAT] <KEY_TYPE>:<PRIMARY_KEY_NAME> <KEY_LENGTH>" <KEYRING> という構文に基づいて、TPM で保護された信頼されたキーに基づく安全な暗号化キーを作成します。

   # keyctl add encrypted encr-key "new trusted:kmk 32" @u
   159771175

   このコマンドは、前の手順で生成した TPM で保護された信頼できる鍵 (kmk) を、暗号化鍵を生成する プライマリーキー として使用します。

手順

1. 無作為な数列を使用してユーザーキーを生成します。

   # keyctl add user kmk-user "$(dd if=/dev/urandom bs=1 count=32 2>/dev/null)" @u
   427069434

   このコマンドは、kmk-user という名前のユーザーキーを生成し、プライマリーキー として動作させ、このユーザーキーを使用して実際の暗号化鍵を保護します。

2. 前の手順で取得したプライマリーキーを使用して、暗号化鍵を生成します。

   # keyctl add encrypted encr-key "new user:kmk-user 32" @u
   1012412758

3. 必要に応じて、指定したユーザーキーリングにあるすべての鍵を一覧表示します。

   # keyctl list @u
   2 keys in keyring:
   427069434: --alswrv  1000  1000 user: kmk-user
   1012412758: --alswrv  1000  1000 encrypted: encr-key

手順

1. 以下のカーネルコマンドラインパラメーターを追加します。

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="ima_policy=appraise_tcb ima_appraise=fix evm=fix"

   このコマンドは、現在のブートエントリーの fix モードで IMA および EVM を有効にしてユーザーが IMA 測定を収集し、更新できるようにします。

   ima_policy=appraise_tcb カーネルコマンドラインパラメーターにより、カーネルは、デフォルトの TCB (Trusted Computing Base) 測定ポリシーと評価手順を使用するようになります。評価部分は、以前の測定と現在の測定が一致しないファイルへのアクセスを禁止します。

2. 再起動して変更を適用します。

3. 必要に応じて、パラメーターがカーネルコマンドラインに追加されていることを確認します。

   # cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-167.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ima_policy=appraise_tcb ima_appraise=fix evm=fix

4. カーネルマスターキーを作成して、EVM 鍵を保護します。

   # keyctl add user kmk "$(dd if=/dev/urandom bs=1 count=32 2> /dev/null)" @u
   748544121

   カーネルマスターキー (kmk) はすべて、カーネル領域メモリーに保持されます。カーネルマスターキー kmk の 32 バイトの Long 値は、/dev/urandom ファイルの乱数バイト数から生成し、ユーザーの (@u) キーリングに配置します。鍵のシリアル番号は、前の出力の 2 行目にあります。

5. kmk 鍵をもとに暗号化された EVM 鍵を作成します。

   # keyctl add encrypted evm-key "new user:kmk 64" @u
   641780271

   kmk を使用して 64 バイトの long 型ユーザーキー (evm-key) を生成してユーザー (@u) のキーリングに配置します。鍵のシリアル番号は、前の出力の 2 行目にあります。

   重要

   ユーザーキーの名前は evm-key (EVM サブシステムが想定して使用している名前) にする必要があります。

6. エクスポートする鍵のディレクトリーを作成します。

   # mkdir -p /etc/keys/

7. kmk 鍵を検索し、その値をファイルにエクスポートします。

   # keyctl pipe $(keyctl search @u user kmk) > /etc/keys/kmk

   このコマンドは、カーネルマスターキー (kmk) の非暗号化値を、以前に定義した場所 (/etc/keys/) にあるファイルに配置します。

8. ユーザーキー evm-key を検索し、その値をファイルにエクスポートします。

   # keyctl pipe $(keyctl search @u encrypted evm-key) > /etc/keys/evm-key

   このコマンドは、ユーザーの evm-key 鍵の暗号化値を、任意の場所にあるファイルに追加します。evm-key は、すでにカーネルのマスターキーにより暗号化されています。

9. 必要に応じて、新規作成されたキーを表示します。

   # keyctl show
   Session Keyring
   974575405   --alswrv     0        0      keyring: ses 299489774 --alswrv 0 65534 \ keyring: uid.0 748544121 --alswrv 0 0 \ user: kmk
   641780271   --alswrv     0        0           \_ encrypted: evm-key
   
   # ls -l /etc/keys/
   total 8
   -rw-r--r--. 1 root root 246 Jun 24 12:44 evm-key
   -rw-r--r--. 1 root root  32 Jun 24 12:43 kmk

   同様の出力が表示されるはずです。

10. EVM をアクティベートします。

    # echo 1 > /sys/kernel/security/evm

11. システム全体の再ラベル付け

    # find / -fstype xfs -type f -uid 0 -exec head -n 1 '{}' >/dev/null \;

    重要

    この手順を省略すると、IMA および EVM を有効にした後に、システム上のほとんどのファイルにアクセスできなくなる場合があります。

手順

1. テストファイルを作成します。

   # echo <Test_text> > test_file

   IMA と EVM は、test_file サンプルファイルにハッシュ値が割り当てられ、その拡張属性として格納されていることを確認します。

2. ファイルの拡張属性を検証します。

   # getfattr -m . -d test_file
   # file: test_file
   security.evm=0sAnDIy4VPA0HArpPO/EqiutnNyBql
   security.ima=0sAQOEDeuUnWzwwKYk+n66h/vby3eD
   security.selinux="unconfined_u:object_r:admin_home_t:s0"

   この出力例は、SELinux および IMA および EVM ハッシュ値に関連する拡張属性を示しています。EVM は、他の属性に関連する security.evm 拡張属性を追加します。security.evm で evmctl ユーティリティーを使用して、RSA ベースのデジタル署名またはハッシュベースのメッセージ認証コード (HMAC-SHA1) を生成できます。前の操作を正常に実行するには、カーネルキーリングに保存されている有効な信頼できるキーまたは暗号化されたキーが必要です。この設定により、拡張属性に対するオフラインの改ざん攻撃が防止されます。

手順

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. 永続的なマッピングのエントリーを /etc/crypttab に追加します。

   1. luksUUID を見つけます。

      # cryptsetup luksUUID /dev/mapper/sdb1_encrypted

      これにより、選択したデバイスの luksUUID が表示されます。

   2. 任意のテキストエディターで /etc/crypttab ファイルを開き、このファイルにデバイスを追加します。

      $ vi /etc/crypttab

      /dev/mapper/sdb1_encrypted luks_uuid none

   3. dracut で initramfs を更新します。

      $ dracut -f --regenerate-all

6. /etc/fstab ファイルに永続的なマウントのエントリーを追加します。

   1. アクティブな LUKS ブロックデバイスの FS UUID を見つけます。

      $ blkid  -p /dev/mapper/sdb1_encrypted

   2. 任意のテキストエディターで /etc/fstab ファイルを開き、このファイルにデバイスを追加します。次に例を示します。

      $ vi  /etc/fstab
      fs__uuid /home auto rw,user,auto 0 0

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

   # 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 restart 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. 認証情報を指定して、ストレージ をクリックします。> をクリックして、Tang サーバーを使用してロックを解除する暗号化されたデバイスの詳細を展開し、Encryption をクリックします。

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

   

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

   

   以下のダイアログウインドウは、鍵ハッシュが一致することを確認するコマンドを提供します。

5. Tang サーバーのターミナルで、tang-show-keys コマンドを使用して、比較のためにキーハッシュを表示します。この例では、Tang サーバーはポート 7500 で実行されています。

   # tang-show-keys 7500
   fM-EwYeiTxS66X3s1UAywsGKGnxnpll8ig0KOQmr9CM

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

   

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

   # yum install clevis-dracut
   # grubby --update-kernel=ALL --args="rd.neednet=1"
   # 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. 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 コマンドが使用します。

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

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

   # yum install clevis-dracut

   RHEL 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

   注記

   Clevis がインストールされているシステムで grubby ツールを使用して、システム起動時の早い段階で Tang ピンのネットワークを利用できるようにすることができます。

   # grubby --update-kernel=ALL --args="rd.neednet=1"

   次に、--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 で暗号化した既存のボリュームを自動的にアンロックするには、サブパッケージの 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 コマンドを使用して、ボリュームを TPM 2.0 デバイスにバインドします。以下に例を示します。

   # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa"}'
   ...
   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 コマンドが使用します。

      あるいは、特定の Platform Configuration Registers (PCR) の状態にデータをシールする場合は、clevis luks bind コマンドに pcr_bank と pcr_ids 値を追加します。以下に例を示します。

      # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa","pcr_bank":"sha256","pcr_ids":"0,1"}'

      警告

      PCR ハッシュ値がシール時に使用されるポリシーと一致し、ハッシュを書き換えることができる場合にのみ、データをアンシールできるため、PCR の値が変更された場合、暗号化されたボリュームのロックを手動で解除できる強力なパスフレーズを追加します。

      shim-x64 パッケージのアップグレード後にシステムが暗号化されたボリュームのロックを自動的に解除できない場合は、KCS の記事Clevis TPM2 no longer decrypts LUKS devices after a restartの手順に従ってください。

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

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

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

検証

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

   # clevis luks list -d /dev/sda2
   1: tpm2 '{"hash":"sha256","key":"rsa"}'

手順

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. 一時パスワードを使用して、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
   clevis-luks
   clevis-systemd
   %end

3. オプションで、必要に応じて暗号化されたボリュームのロックを手動で解除できるようにするには、一時パスフレーズを削除する前に強力なパスフレーズを追加します。詳細については、How to add a passphrase, key, or keyfile to an existing LUKS device の記事を参照してください。

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

   %post
   clevis luks bind -y -k - -d /dev/vda2 \
   tang '{"url":"http://tang.srv"}' <<< "temppass"
   cryptsetup luksRemoveKey /dev/vda2 <<< "temppass"
   dracut -fv --regenerate-all
   %end

   設定が起動初期にネットワークを必要とする Tang ピンに依存している場合、または静的 IP 設定の NBDE クライアントを使用している場合は、Configuring manual enrollment of LUKS-encrypted volumesに従って dracut コマンドを変更する必要があります。

   clevis luks bind コマンドの -y オプションは、RHEL 8.3 から使用できることに注意してください。RHEL 8.2 以前では、 clevis luks bind コマンドで -y を -f に置き換え、Tang サーバーからアドバタイズメントをダウンロードします。

   %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"
   dracut -fv --regenerate-all
   %end

   警告

   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 レジストリーから tang コンテナーイメージをプルします。

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

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

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

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

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

   # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/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. 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

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

   # vi my-tang-playbook.yml

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

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

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

   # ansible-playbook -i inventory-file my-tang-playbook.yml

   ここで、* inventory-file はインベントリーファイルに置き換えます。* logging-playbook.yml は、使用する Playbook に置き換えます。

手順

1. 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

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

   # vi my-clevis-playbook.yml

3. 必要なパラメーターを追加します。以下の 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:
       - rhel-system-roles.nbde_client

4. 終了した 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. RHEL 8.6 以降では、事前設定されたルールファイル 44-installers.rules を /usr/share/audit/sample-rules/ ディレクトリーから /etc/audit/rules.d/ ディレクトリーにコピーします。

   # cp /usr/share/audit/sample-rules/44-installers.rules /etc/audit/rules.d/

   RHEL 8.5 以前では、/etc/audit/rules.d/ ディレクトリーに、44-installers.rules という名前の新規ファイルを作成し、以下のルールを挿入します。

   -a always,exit -F perm=x -F path=/usr/bin/dnf-3 -F key=software-installer
   -a always,exit -F perm=x -F path=/usr/bin/yum -F

   同じ構文を使用して、pip や npm などのソフトウェアをインストールする他のユーティリティー用に、さらにルールを追加できます。

2. 監査ルールを読み込みます。

   # augenrules --load

検証

1. 読み込まれたルールを一覧表示します。

   # auditctl -l
   -p x-w /usr/bin/dnf-3 -k software-installer
   -p x-w /usr/bin/yum -k software-installer
   -p x-w /usr/bin/pip -k software-installer
   -p x-w /usr/bin/npm -k software-installer
   -p x-w /usr/bin/cpan -k software-installer
   -p x-w /usr/bin/gem -k software-installer
   -p x-w /usr/bin/luarocks -k software-installer

2. インストールを実行します。以下に例を示します

   # yum reinstall -y vim-enhanced

3. Audit ログで最近のインストールイベントを検索します。次に例を示します。

   # ausearch -ts recent -k software-installer
   ––––
   time->Thu Dec 16 10:33:46 2021
   type=PROCTITLE msg=audit(1639668826.074:298): proctitle=2F7573722F6C6962657865632F706C6174666F726D2D707974686F6E002F7573722F62696E2F646E66007265696E7374616C6C002D790076696D2D656E68616E636564
   type=PATH msg=audit(1639668826.074:298): item=2 name="/lib64/ld-linux-x86-64.so.2" inode=10092 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=PATH msg=audit(1639668826.074:298): item=1 name="/usr/libexec/platform-python" inode=4618433 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=PATH msg=audit(1639668826.074:298): item=0 name="/usr/bin/dnf" inode=6886099 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:rpm_exec_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
   type=CWD msg=audit(1639668826.074:298): cwd="/root"
   type=EXECVE msg=audit(1639668826.074:298): argc=5 a0="/usr/libexec/platform-python" a1="/usr/bin/dnf" a2="reinstall" a3="-y" a4="vim-enhanced"
   type=SYSCALL msg=audit(1639668826.074:298): arch=c000003e syscall=59 success=yes exit=0 a0=55c437f22b20 a1=55c437f2c9d0 a2=55c437f2aeb0 a3=8 items=3 ppid=5256 pid=5375 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=3 comm="dnf" exe="/usr/libexec/platform-python3.6" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="software-installer"

手順

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. カスタムバイナリーを信頼済みとしてマークし、対応するエントリーを /etc/fapolicyd/trust.d/ の myapp ファイルに保存します。

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

   • --trust-file オプションをスキップすると、前のコマンドは対応する行を /etc/fapolicyd/fapolicyd.trust に追加します。
   • ディレクトリー内のすべての既存ファイルを信頼済みとしてマークするには、--file オプションの引数としてディレクトリーパスを指定します。たとえば、fapolicyd-cli --file add/tmp/my_bin_dir/--trust-file myapp です。

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

   # fapolicyd-cli --update

検証

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

   $ /tmp/ls
   ls