セキュリティーの強化

手順

1. RHEL 9 Web コンソールにログインします。

   詳細は、Web コンソールへのログイン を参照してください。

2. Overview タブで、System information フィールドを見つけて、View hardware details をクリックします。

3. CPU Security 行で、Mitigations をクリックします。

   このリンクがない場合は、システムが SMT に対応していないため、攻撃を受けません。

4. CPU Security Toggles テーブルで、Disable simultaneous multithreading (nosmt) オプションに切り替えます。
5. Save and reboot ボタンをクリックします。

手順

1. システムのインストール時に fips=1 オプションをカーネルコマンドラインに追加します。
2. ソフトウェアの選択段階で、サードパーティーのソフトウェアをインストールしないでください。
3. インストール後に、システムは FIPS モードで自動的に起動します。

手順

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. オプション: 現在の暗号化ポリシーを表示します。

   $ update-crypto-policies --show
   DEFAULT

2. 新しい暗号化ポリシーを設定します。

   # update-crypto-policies --set <POLICY>
   <POLICY>

   <POLICY> は、設定するポリシーまたはサブポリシー (FUTURE、LEGACY、FIPS:OSPP など) に置き換えます。

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

   # reboot

手順

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

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

手順

1. SHA1 サブポリシーを DEFAULT 暗号化ポリシーに適用します。

   # update-crypto-policies --set DEFAULT:SHA1
   Setting system policy to DEFAULT:SHA1
   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.

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

   # reboot

手順

1. RHEL 9 Web コンソールにログインします。

   詳細は、Web コンソールへのログイン を参照してください。

2. Overview ページの Configuration カードで、Crypto policy の横にある現在のポリシー値をクリックします。

   

3. Change crypto policy ダイアログウィンドウで、システムで使用を開始するポリシーをクリックします。

   

4. Apply and reboot ボタンをクリックします。

手順

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. カスタマイズのポリシーファイルを作成します。

   # 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 ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure crypto policies
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure crypto policies
         ansible.builtin.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 を設定すると、システムロールが暗号化ポリシーを変更した後にシステムが再起動します。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

検証

1. コントロールノードで、たとえば verify_playbook.yml という名前の別の Playbook を作成します。

   ---
   - name: Verification
     hosts: managed-node-01.example.com
     tasks:
       - name: Verify active crypto policy
         ansible.builtin.include_role:
           name: rhel-system-roles.crypto_policies
       - debug:
           var: crypto_policies_active

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/verify_playbook.yml

3. Playbook を実行します。

   $ ansible-playbook ~/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. --remediate オプションを指定した oscap コマンドを使用してシステムを修復します。

   # oscap xccdf eval --profile <profileID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

   <profileID> は、システムが準拠する必要があるプロファイル ID (例: hipaa) に置き換えます。

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

検証

1. システムがプロファイルに準拠しているかどうかを評価し、スキャン結果をファイルに保存します。

   $ oscap xccdf eval --report <scan-report.html> --profile <profileID> /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

   以下を置き換えます。

   • <scan-report.html> は、oscap がスキャン結果を保存するファイル名です。
   • <profileID> は、システムが準拠する必要があるプロファイル ID (例: hipaa) です。

手順

1. Ansible を使用して、HIPAA に準拠するようにシステムを修正します。

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

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

検証

1. システムが HIPAA プロファイルに準拠しているかどうかを評価し、スキャン結果をファイルに保存します。

   # oscap xccdf eval --profile hipaa --report <scan-report.html> /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

   <scan-report.html> は、oscap がスキャン結果を保存するファイル名に置き換えます。

手順

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

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

2. 結果が含まれるファイルで、結果 ID の値を見つけます。

   # oscap info <hipaa-results.xml>

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

   # oscap xccdf generate fix --fix-type ansible --result-id <xccdf_org.open-scap_testresult_xccdf_org.ssgproject.content_profile_hipaa> --output <hipaa-remediations.yml> <hipaa-results.xml>

4. 生成されたファイルを確認します。これには、手順 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-rhel9-ds.xml

2. 結果が含まれるファイルで、結果 ID の値を見つけます。

   # oscap info <hipaa-results.xml>

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

   # oscap xccdf generate fix --fix-type bash --result-id <xccdf_org.open-scap_testresult_xccdf_org.ssgproject.content_profile_hipaa> --output <hipaa-remediations.sh> <hipaa-results.xml>

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

手順

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

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

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

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

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

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

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

手順

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

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

2. コンテナーイメージがプロファイルに準拠しているかどうかを評価し、スキャン結果をファイルに保存します。

   # oscap-podman <imageID> xccdf eval --report <scan-report.html> --profile <profileID> /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

   以下を置き換えます。

   • <imageID> は、コンテナーイメージの ID です。
   • <scan-report.html> は、oscap がスキャン結果を保存するファイル名です。
   • <profileID> は、システムが準拠する必要があるプロファイル ID (例: hipaa、ospp、pci-dss) です。

手順

1. Keylime verifier をインストールします。

   # dnf install keylime-verifier

2. /etc/keylime/verifier.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/verifier.conf.d/00-verifier-ip.conf など) を作成して、verifier の IP アドレスとポートを定義します。

   [verifier]
   ip = <verifier_IP_address>

   • <verifier_IP_address> は、verifier の IP アドレスに置き換えます。あるいは、ip = * または ip = 0.0.0.0 を使用して、使用可能なすべての IP アドレスに verifier をバインドします。
   • 必要に応じて、port オプションを使用して、verifier のポートをデフォルト値 8881 から変更することもできます。

3. オプション: エージェントのリスト用に verifier のデータベースを設定します。デフォルトの設定では、verifier の /var/lib/keylime/cv_data.sqlite ディレクトリーにある SQLite データベースを使用します。/etc/keylime/verifier.conf.d/ ディレクトリーに次の内容の新しい .conf ファイル (/etc/keylime/verifier.conf.d/00-db-ip.conf など) を作成することで、別のデータベースを定義できます。

   [verifier]
   database_url = <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties>

   <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties> は、データベースの URL (例: postgresql://verifier:UQ?nRNY9g7GZzN7@198.51.100.1/verifierdb) に置き換えます。

   使用する認証情報が、Keylime にデータベース構造を作成するための権限を提供していることを確認してください。

4. verifier に証明書と鍵を追加します。Keylime にそれらを生成させることも、既存の鍵と証明書を使用することもできます。

   • デフォルトの tls_dir =generate オプションを使用すると、Keylime は verifier、registrar、およびテナントの新しい証明書を /var/lib/keylime/cv_ca/ ディレクトリーに生成します。

   • 既存の鍵と証明書を設定にロードするには、verifier 設定でそれらの場所を定義します。Keylime サービスの実行者である keylime ユーザーが証明書にアクセスできる必要があります。

     /etc/keylime/verifier.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/verifier.conf.d/00-keys-and-certs.conf など) を作成します。

     [verifier]
     tls_dir = /var/lib/keylime/cv_ca
     server_key = </path/to/server_key>
     server_key_password = <passphrase1>
     server_cert = </path/to/server_cert>
     trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']
     client_key = </path/to/client_key>
     client_key_password = <passphrase2>
     client_cert = </path/to/client_cert>
     trusted_server_ca = ['</path/to/ca/cert3>', '</path/to/ca/cert4>']

     注記

     絶対パスを使用して、鍵と証明書の場所を定義します。また、相対パスは tls_dir オプションで定義されたディレクトリーから解決されます。

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

   # firewall-cmd --add-port 8881/tcp
   # firewall-cmd --runtime-to-permanent

   別のポートを使用する場合は、8881 を .conf ファイルで定義されているポート番号に置き換えます。

6. verifier サービスを開始します。

   # systemctl enable --now keylime_verifier

   注記

   デフォルト設定では、verifier が他の Keylime コンポーネントの CA と証明書を作成するため、keylime_registrar サービスを起動する前に keylime_verifier を起動します。カスタム証明書を使用する場合、この順序で起動する必要はありません。

手順

1. オプション: 設定ファイルにアクセスするには、keylime-verifier パッケージをインストールします。このパッケージがなくてもコンテナーを設定することはできますが、パッケージに付属する設定ファイルを変更する方が簡単な場合があります。

   # dnf install keylime-verifier

2. /etc/keylime/verifier.conf.d/ ディレクトリーに新しい .conf ファイル (例: /etc/keylime/verifier.conf.d/00-verifier-ip.conf) を作成し、次の内容を記述して、verifier をすべての使用可能な IP アドレスにバインドします。

   [verifier]
   ip = *

   • 必要に応じて、port オプションを使用して、verifier のポートをデフォルト値 8881 から変更することもできます。

3. オプション: エージェントのリスト用に verifier のデータベースを設定します。デフォルトの設定では、verifier の /var/lib/keylime/cv_data.sqlite ディレクトリーにある SQLite データベースを使用します。/etc/keylime/verifier.conf.d/ ディレクトリーに次の内容の新しい .conf ファイル (/etc/keylime/verifier.conf.d/00-db-ip.conf など) を作成することで、別のデータベースを定義できます。

   [verifier]
   database_url = <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties>

   <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties> は、データベースの URL (例: postgresql://verifier:UQ?nRNY9g7GZzN7@198.51.100.1/verifierdb) に置き換えます。

   使用する認証情報に、Keylime がデータベース構造を作成するための権限があることを確認してください。

4. verifier に証明書と鍵を追加します。Keylime にそれらを生成させることも、既存の鍵と証明書を使用することもできます。

   • デフォルトの tls_dir =generate オプションを使用すると、Keylime は verifier、registrar、およびテナントの新しい証明書を /var/lib/keylime/cv_ca/ ディレクトリーに生成します。

   • 既存の鍵と証明書を設定にロードするには、verifier 設定でそれらの場所を定義します。Keylime プロセスの実行者である keylime ユーザーが証明書にアクセスできる必要があります。

     /etc/keylime/verifier.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/verifier.conf.d/00-keys-and-certs.conf など) を作成します。

     [verifier]
     tls_dir = /var/lib/keylime/cv_ca
     server_key = </path/to/server_key>
     server_cert = </path/to/server_cert>
     trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']
     client_key = </path/to/client_key>
     client_cert = </path/to/client_cert>
     trusted_server_ca = ['</path/to/ca/cert3>', '</path/to/ca/cert4>']

     注記

     絶対パスを使用して、鍵と証明書の場所を定義します。また、相対パスは tls_dir オプションで定義されたディレクトリーから解決されます。

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

   # firewall-cmd --add-port 8881/tcp
   # firewall-cmd --runtime-to-permanent

   別のポートを使用する場合は、8881 を .conf ファイルで定義されているポート番号に置き換えます。

6. コンテナーを実行します。

   $ podman run --name keylime-verifier \
     -p 8881:8881 \
     -v /etc/keylime/verifier.conf.d:/etc/keylime/verifier.conf.d:Z \
     -v /var/lib/keylime/cv_ca:/var/lib/keylime/cv_ca:Z \
     -d \
     -e KEYLIME_VERIFIER_SERVER_KEY_PASSWORD=<passphrase1> \
     -e KEYLIME_VERIFIER_CLIENT_KEY_PASSWORD=<passphrase2> \
     registry.access.redhat.com/rhel9/keylime-verifier

   • -p オプションは、ホスト上とコンテナー上のデフォルトポート 8881 を開きます。

   • -v オプションは、コンテナーへのディレクトリーのバインドマウントを作成します。

     • Z オプションを指定すると、Podman がコンテンツにプライベート非共有ラベルを付けます。つまり、現在のコンテナーだけがプライベートボリュームを使用できます。
   • -d オプションは、コンテナーをデタッチしてバックグラウンドで実行します。
   • オプション -e KEYLIME_VERIFIER_SERVER_KEY_PASSWORD=<passphrase1> は、サーバーの鍵のパスフレーズを定義します。
   • オプション -e KEYLIME_VERIFIER_CLIENT_KEY_PASSWORD=<passphrase2> は、クライアントの鍵のパスフレーズを定義します。
   • オプション -e KEYLIME_VERIFIER_<ENVIRONMENT_VARIABLE>=<value> を指定すると、環境変数で設定オプションをオーバーライドできます。複数のオプションを変更するには、環境変数ごとに -e オプションを個別に挿入します。環境変数とそのデフォルト値の完全なリストについては、Keylime の環境変数 を参照してください。

手順

1. Keylime registrar をインストールします。

   # dnf install keylime-registrar

2. /etc/keylime/registrar.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/registrar.conf.d/00-registrar-ip.conf など) を作成して、registrar の IP アドレスとポートを定義します。

   [registrar]
   ip = <registrar_IP_address>

   • <registrar_IP_address> を registrar の IP アドレスに置き換えます。あるいは、ip = * または ip = 0.0.0.0 を使用して、使用可能なすべての IP アドレスに registrar をバインドします。
   • 必要に応じて、port オプションを使用して、Keylime エージェントが接続するポートを変更します。デフォルト値は 8890 です。
   • 必要に応じて、tls_port オプションを使用して、Keylime verifier とテナントが接続する TLS ポートを変更します。デフォルト値は 8891 です。

3. オプション: エージェントのリスト用に registrar のデータベースを設定します。デフォルト設定では、registrar の /var/lib/keylime/reg_data.sqlite ディレクトリーにある SQLite データベースを使用します。/etc/keylime/registrar.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/registrar.conf.d/00-db-url.conf など) を作成できます。

   [registrar]
   database_url = <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties>

   <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties> は、データベースの URL (例: postgresql://registrar:EKYYX-bqY2?#raXm@198.51.100.1/registrardb) に置き換えます。

   使用する認証情報に、Keylime がデータベース構造を作成するための権限があることを確認してください。

4. registrar に証明書と鍵を追加します。

   • デフォルトの設定を使用して、鍵と証明書を /var/lib/keylime/reg_ca ディレクトリーにロードできます。

   • または、設定で鍵と証明書の場所を定義することもできます。/etc/keylime/registrar.conf.d/ ディレクトリーに新しい .conf ファイルを作成します (例: /etc/keylime/registrar.conf.d/00-keys-and-certs.conf の内容は次のとおりです)。

     [registrar]
     tls_dir = /var/lib/keylime/reg_ca
     server_key = </path/to/server_key>
     server_key_password = <passphrase1>
     server_cert = </path/to/server_cert>
     trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']

     注記

     絶対パスを使用して、鍵と証明書の場所を定義します。または、tls_dir オプションでディレクトリーを定義し、そのディレクトリーからの相対パスを使用することもできます。

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

   # firewall-cmd --add-port 8890/tcp --add-port 8891/tcp
   # firewall-cmd --runtime-to-permanent

   別のポートを使用する場合は、8890 または 8891 を .conf ファイルで定義されているポート番号に置き換えます。

6. keylime_registrar サービスを起動します。

   # systemctl enable --now keylime_registrar

   注記

   デフォルト設定では、verifier が他の Keylime コンポーネントの CA と証明書を作成するため、keylime_registrar サービスを起動する前に keylime_verifier を起動します。カスタム証明書を使用する場合、この順序で起動する必要はありません。

手順

1. オプション: 設定ファイルにアクセスするには、keylime-registrar パッケージをインストールします。このパッケージがなくてもコンテナーを設定することはできますが、パッケージに付属する設定ファイルを変更する方が簡単な場合があります。

   # dnf install keylime-registrar

2. /etc/keylime/registrar.conf.d/ ディレクトリーに新しい .conf ファイル (例: /etc/keylime/registrar.conf.d/00-registrar-ip.conf) を作成し、次の内容を記述して、registrar を使用可能なすべての IP アドレスにバインドします。

   [registrar]
   ip = *

   • 必要に応じて、port オプションを使用して、Keylime エージェントが接続するポートを変更します。デフォルト値は 8890 です。
   • 必要に応じて、tls_port オプションを使用して、Keylime テナントが接続する TLS ポートを変更します。デフォルト値は 8891 です。

3. オプション: エージェントのリスト用に registrar のデータベースを設定します。デフォルト設定では、registrar の /var/lib/keylime/reg_data.sqlite ディレクトリーにある SQLite データベースを使用します。/etc/keylime/registrar.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/registrar.conf.d/00-db-url.conf など) を作成できます。

   [registrar]
   database_url = <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties>

   <protocol>://<name>:<password>@<ip_address_or_hostname>/<properties> は、データベースの URL (例: postgresql://registrar:EKYYX-bqY2?#raXm@198.51.100.1/registrardb) に置き換えます。

   使用する認証情報に、Keylime がデータベース構造を作成するための権限があることを確認してください。

4. registrar に証明書と鍵を追加します。

   • デフォルトの設定を使用して、鍵と証明書を /var/lib/keylime/reg_ca ディレクトリーにロードできます。

   • または、設定で鍵と証明書の場所を定義することもできます。/etc/keylime/registrar.conf.d/ ディレクトリーに新しい .conf ファイルを作成します (例: /etc/keylime/registrar.conf.d/00-keys-and-certs.conf の内容は次のとおりです)。

     [registrar]
     tls_dir = /var/lib/keylime/reg_ca
     server_key = </path/to/server_key>
     server_cert = </path/to/server_cert>
     trusted_client_ca = ['</path/to/ca/cert1>', '</path/to/ca/cert2>']

     注記

     絶対パスを使用して、鍵と証明書の場所を定義します。または、tls_dir オプションでディレクトリーを定義し、そのディレクトリーからの相対パスを使用することもできます。

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

   # firewall-cmd --add-port 8890/tcp --add-port 8891/tcp
   # firewall-cmd --runtime-to-permanent

   別のポートを使用する場合は、8890 または 8891 を .conf ファイルで定義されているポート番号に置き換えます。

6. コンテナーを実行します。

   $ podman run --name keylime-registrar \
     -p 8890:8890 \
     -p 8891:8891 \
     -v /etc/keylime/registrar.conf.d:/etc/keylime/registrar.conf.d:Z \
     -v /var/lib/keylime/reg_ca:/var/lib/keylime/reg_ca:Z \
     -d \
     -e KEYLIME_REGISTRAR_SERVER_KEY_PASSWORD=<passphrase1> \
     registry.access.redhat.com/rhel9/keylime-registrar

   • -p オプションは、ホスト上とコンテナー上のデフォルトポート 8890 および 8881 を開きます。

   • -v オプションは、コンテナーへのディレクトリーのバインドマウントを作成します。

     • Z オプションを指定すると、Podman がコンテンツにプライベート非共有ラベルを付けます。つまり、現在のコンテナーだけがプライベートボリュームを使用できます。
   • -d オプションは、コンテナーをデタッチしてバックグラウンドで実行します。
   • オプション -e KEYLIME_VERIFIER_SERVER_KEY_PASSWORD=<passphrase1> は、サーバーの鍵のパスフレーズを定義します。
   • オプション -e KEYLIME_REGISTRAR_<ENVIRONMENT_VARIABLE>=<value> を指定すると、環境変数で設定オプションをオーバーライドできます。複数のオプションを変更するには、環境変数ごとに -e オプションを個別に挿入します。環境変数とそのデフォルト値の完全なリストについては、「Keylime の環境変数」 を参照してください。

手順

1. 必要なロールを定義する Playbook を作成します。

   1. 新しい YAML ファイルを作成し、これをテキストエディターで開きます。以下に例を示します。

      # vi keylime-playbook.yml

   2. 以下の内容を挿入します。

      ---
      - name: Manage keylime servers
        hosts: all
        vars:
          keylime_server_verifier_ip: "{{ ansible_host }}"
          keylime_server_registrar_ip: "{{ ansible_host }}"
          keylime_server_verifier_tls_dir: <ver_tls_directory>
          keylime_server_verifier_server_cert: <ver_server_certfile>
          keylime_server_verifier_server_key: <ver_server_key>
          keylime_server_verifier_server_key_passphrase: <ver_server_key_passphrase>
          keylime_server_verifier_trusted_client_ca: <ver_trusted_client_ca_list>
          keylime_server_verifier_client_cert: <ver_client_certfile>
          keylime_server_verifier_client_key: <ver_client_key>
          keylime_server_verifier_client_key_passphrase: <ver_client_key_passphrase>
          keylime_server_verifier_trusted_server_ca: <ver_trusted_server_ca_list>
          keylime_server_registrar_tls_dir: <reg_tls_directory>
          keylime_server_registrar_server_cert: <reg_server_certfile>
          keylime_server_registrar_server_key: <reg_server_key>
          keylime_server_registrar_server_key_passphrase: <reg_server_key_passphrase>
          keylime_server_registrar_trusted_client_ca: <reg_trusted_client_ca_list>
        roles:
          - rhel-system-roles.keylime_server

      変数の詳細は、keylime_server RHEL システムロールの変数 を参照してください。

2. Playbook を実行します。

   $ ansible-playbook <keylime-playbook.yml>

検証

1. keylime_verifier サービスがアクティブであり、管理対象ホスト上で実行されていることを確認します。

   # systemctl status keylime_verifier
   ● keylime_verifier.service - The Keylime verifier
        Loaded: loaded (/usr/lib/systemd/system/keylime_verifier.service; disabled; vendor preset: disabled)
        Active: active (running) since Wed 2022-11-09 10:10:08 EST; 1min 45s ago

2. keylime_registrar サービスがアクティブで実行中であることを確認します。

   # systemctl status keylime_registrar
   ● keylime_registrar.service - The Keylime registrar service
        Loaded: loaded (/usr/lib/systemd/system/keylime_registrar.service; disabled; vendor preset: disabled)
        Active: active (running) since Wed 2022-11-09 10:10:17 EST; 1min 42s ago
   ...

手順

1. Keylime テナントをインストールします。

   # dnf install keylime-tenant

2. /etc/keylime/tenant.conf.d/00-verifier-ip.conf ファイルを編集して、Keylime verifier へのテナントの接続を定義します。

   [tenant]
   verifier_ip = <verifier_ip>

   • <verifier_ip> は、verifier のシステムの IP アドレスに置き換えます。
   • verifier がデフォルト値 8881 とは異なるポートを使用する場合は、verifier_port = <verifier_port> 設定を追加します。

3. /etc/keylime/tenant.conf.d/00-registrar-ip.conf ファイルを編集して、Keylime registrar へのテナントの接続を定義します。

   [tenant]
   registrar_ip = <registrar_ip>

   • <registrar_ip> は、registrar のシステムの IP アドレスに置き換えます。
   • registrar がデフォルト値 8891 とは異なるポートを使用する場合は、registrar_port = <registrar_port> 設定を追加します。

4. テナントに証明書と鍵を追加します。

   1. デフォルトの設定を使用して、鍵と証明書を /var/lib/keylime/cv_ca ディレクトリーにロードできます。

   2. または、設定で鍵と証明書の場所を定義することもできます。/etc/keylime/tenant.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/tenant.conf.d/00-keys-and-certs.conf など) を作成します。

      [tenant]
      tls_dir = /var/lib/keylime/cv_ca
      client_key = tenant-key.pem
      client_key_password = <passphrase1>
      client_cert = tenant-cert.pem
      trusted_server_ca = ['</path/to/ca/cert>']

      trusted_server_ca パラメーターは、verifier および registrar サーバーの CA 証明書へのパスを受け入れます。verifier と registrar が異なる CA を使用する場合などに、複数のコンマ区切りのパスを指定できます。

      注記

      絶対パスを使用して、鍵と証明書の場所を定義します。または、tls_dir オプションでディレクトリーを定義し、そのディレクトリーからの相対パスを使用することもできます。

5. オプション: /var/lib/keylime/tpm_cert_store ディレクトリー内の証明書を使用して Trusted Platform Module (TPM) の保証鍵 (EK) を検証できない場合は、証明書をそのディレクトリーに追加します。これは、エミュレートされた TPM を備えた仮想マシンを使用する場合に特に発生する可能性があります。

検証

1. verifier のステータスを確認します。

   # keylime_tenant -c cvstatus
   Reading configuration from ['/etc/keylime/logging.conf']
   2022-10-14 12:56:08.155 - keylime.tpm - INFO - TPM2-TOOLS Version: 5.2
   Reading configuration from ['/etc/keylime/tenant.conf']
   2022-10-14 12:56:08.157 - keylime.tenant - INFO - Setting up client TLS...
   2022-10-14 12:56:08.158 - keylime.tenant - INFO - Using default client_cert option for tenant
   2022-10-14 12:56:08.158 - keylime.tenant - INFO - Using default client_key option for tenant
   2022-10-14 12:56:08.178 - keylime.tenant - INFO - TLS is enabled.
   2022-10-14 12:56:08.178 - keylime.tenant - WARNING - Using default UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000
   2022-10-14 12:56:08.221 - keylime.tenant - INFO - Verifier at 127.0.0.1 with Port 8881 does not have agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000.

   正しくセットアップされていて、エージェントが設定されていない場合、verifier は、デフォルトのエージェント UUID を認識しないと応答します。

2. registrar のステータスを確認します。

   # keylime_tenant -c regstatus
   Reading configuration from ['/etc/keylime/logging.conf']
   2022-10-14 12:56:02.114 - keylime.tpm - INFO - TPM2-TOOLS Version: 5.2
   Reading configuration from ['/etc/keylime/tenant.conf']
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Setting up client TLS...
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Using default client_cert option for tenant
   2022-10-14 12:56:02.116 - keylime.tenant - INFO - Using default client_key option for tenant
   2022-10-14 12:56:02.137 - keylime.tenant - INFO - TLS is enabled.
   2022-10-14 12:56:02.137 - keylime.tenant - WARNING - Using default UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000
   2022-10-14 12:56:02.171 - keylime.registrar_client - CRITICAL - Error: could not get agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 data from Registrar Server: 404
   2022-10-14 12:56:02.172 - keylime.registrar_client - CRITICAL - Response code 404: agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 not found
   2022-10-14 12:56:02.172 - keylime.tenant - INFO - Agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 does not exist on the registrar. Please register the agent with the registrar.
   2022-10-14 12:56:02.172 - keylime.tenant - INFO - {"code": 404, "status": "Agent d432fbb3-d2f1-4a97-9ef7-75bd81c00000 does not exist on registrar 127.0.0.1 port 8891.", "results": {}}

   正しくセットアップされていて、エージェントが設定されていない場合、registrar は、デフォルトのエージェント UUID を認識しないと応答します。

手順

1. Keylime エージェントをインストールします。

   # dnf install keylime-agent

   このコマンドは、keylime-agent-rust パッケージをインストールします。

2. 設定ファイルでエージェントの IP アドレスとポートを定義します。/etc/keylime/agent.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/agent.conf.d/00-agent-ip.conf など) を作成します。

   [agent]
   ip = '<agent_ip>'

   注記

   Keylime エージェントの設定では TOML 形式が使用されます。これは、他のコンポーネントの設定に使用される INI 形式とは異なります。したがって、値は有効な TOML 構文で入力してください。たとえば、パスは一重引用符で囲み、複数のパスの配列は角括弧で囲みます。

   • <agent_IP_address> は、エージェントの IP アドレスに置き換えます。あるいは、ip = '*' または ip = '0.0.0.0' を使用して、使用可能なすべての IP アドレスにエージェントをバインドします。
   • 必要に応じて、port = '<agent_port>' オプションを使用して、エージェントのポートをデフォルト値 9002 から変更することもできます。

3. 設定ファイルで registrar の IP アドレスとポートを定義します。/etc/keylime/agent.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/agent.conf.d/00-registrar-ip.conf など) を作成します。

   [agent]
   registrar_ip = '<registrar_IP_address>'

   • <registrar_IP_address> を registrar の IP アドレスに置き換えます。
   • 必要に応じて、registrar_port = '<registrar_port>' オプションを使用して、registrar のポートをデフォルト値 8890 から変更することもできます。

4. オプション: エージェントの汎用一意識別子 (UUID) を定義します。定義されていない場合は、デフォルトの UUID が使用されます。/etc/keylime/agent.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/agent.conf.d/00-agent-uuid.conf など) を作成します。

   [agent]
   uuid = '<agent_UUID>'

   • <agent_UUID> は、エージェントの UUID に置き換えます (例: d432fbb3-d2f1-4a97-9ef7-abcdef012345)。uuidgen ユーティリティーを使用して UUID を生成できます。

5. オプション: エージェントの既存の鍵と証明書をロードします。エージェントが server_key と server_cert を受信しない場合、エージェントは独自の鍵と自己署名証明書を生成します。

   設定で鍵と証明書の場所を定義します。/etc/keylime/agent.conf.d/ ディレクトリーに、次の内容の新しい .conf ファイル (/etc/keylime/agent.conf.d/00-keys-and-certs.conf など) を作成します。

   [agent]
   server_key = '</path/to/server_key>'
   server_key_password = '<passphrase1>'
   server_cert = '</path/to/server_cert>'
   trusted_client_ca = '[</path/to/ca/cert3>, </path/to/ca/cert4>]'

   注記

   絶対パスを使用して、鍵と証明書の場所を定義します。Keylim エージェントは相対パスを受け入れません。

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

   # firewall-cmd --add-port 9002/tcp
   # firewall-cmd --runtime-to-permanent

   別のポートを使用する場合は、9002 を .conf ファイルで定義されているポート番号に置き換えます。

7. keylime_agent サービスを有効にして起動します。

   # systemctl enable --now keylime_agent

8. オプション: Keylime テナントが設定されているシステムから、エージェントが正しく設定されており、registrar に接続できることを確認します。

   # keylime_tenant -c regstatus --uuid <agent_uuid>
   Reading configuration from ['/etc/keylime/logging.conf']
   ...
   ==\n-----END CERTIFICATE-----\n", "ip": "127.0.0.1", "port": 9002, "regcount": 1, "operational_state": "Registered"}}}

   • <agent_uuid> は、エージェントの UUID に置き換えます。

     registrar と agent が正しく設定されている場合、出力にはエージェントの IP アドレスとポートが表示され、その後に "operational_state":"Registered" が表示されます。

9. /etc/ima/ima-policy ファイルに次の内容を入力して、新しい IMA ポリシーを作成します。

   # PROC_SUPER_MAGIC = 0x9fa0
   dont_measure fsmagic=0x9fa0
   # SYSFS_MAGIC = 0x62656572
   dont_measure fsmagic=0x62656572
   # DEBUGFS_MAGIC = 0x64626720
   dont_measure fsmagic=0x64626720
   # TMPFS_MAGIC = 0x01021994
   dont_measure fsmagic=0x1021994
   # RAMFS_MAGIC
   dont_measure fsmagic=0x858458f6
   # DEVPTS_SUPER_MAGIC=0x1cd1
   dont_measure fsmagic=0x1cd1
   # BINFMTFS_MAGIC=0x42494e4d
   dont_measure fsmagic=0x42494e4d
   # SECURITYFS_MAGIC=0x73636673
   dont_measure fsmagic=0x73636673
   # SELINUX_MAGIC=0xf97cff8c
   dont_measure fsmagic=0xf97cff8c
   # SMACK_MAGIC=0x43415d53
   dont_measure fsmagic=0x43415d53
   # NSFS_MAGIC=0x6e736673
   dont_measure fsmagic=0x6e736673
   # EFIVARFS_MAGIC
   dont_measure fsmagic=0xde5e81e4
   # CGROUP_SUPER_MAGIC=0x27e0eb
   dont_measure fsmagic=0x27e0eb
   # CGROUP2_SUPER_MAGIC=0x63677270
   dont_measure fsmagic=0x63677270
   # OVERLAYFS_MAGIC
   # when containers are used we almost always want to ignore them
   dont_measure fsmagic=0x794c7630
   # MEASUREMENTS
   measure func=BPRM_CHECK
   measure func=FILE_MMAP mask=MAY_EXEC
   measure func=MODULE_CHECK uid=0

   このポリシーは、実行されたアプリケーションのランタイム監視をターゲットとしています。このポリシーは状況に応じて調整できます。MAGIC 定数については、statfs(2) man ページを参照してください。

10. カーネルパラメーターを更新します。

    # grubby --update-kernel DEFAULT --args 'ima_appraise=fix ima_canonical_fmt ima_policy=tcb ima_template=ima-ng'

11. システムを再起動して、新しい IMA ポリシーを適用します。

検証

1. エージェントが実行されていることを確認します。

   # systemctl status keylime_agent
   ● keylime_agent.service - The Keylime compute agent
        Loaded: loaded (/usr/lib/systemd/system/keylime_agent.service; enabled; preset: disabled)
        Active: active (running) since ...

手順

1. Keylime エージェントが設定され実行されている監視対象システムで、システムの現在の状態から許可リストを生成します。

   # /usr/share/keylime/scripts/create_allowlist.sh -o <allowlist.txt> -h sha256sum

   <allowlist.txt> を許可リストのファイル名に置き換えます。

   重要

   SHA-256 ハッシュ関数を使用します。SHA-1 は安全ではなく、RHEL 9 で廃止されました。追加情報は、SHA-1 deprecation in Red Hat Enterprise Linux 9 を参照してください。

2. 生成された許可リストを、keylime_tenant ユーティリティーが設定されているシステムにコピーします。次に例を示します。

   # scp <allowlist.txt> root@<tenant.ip>:/root/<allowlist.txt>

3. オプション: Keylime の測定から除外するファイルまたはディレクトリーのリストを定義するには、テナントシステム上にファイルを作成し、除外するファイルおよびディレクトリーのパスを入力します。除外リストでは、1 行に 1 つの Python 正規表現を使用できます。特殊文字の完全なリストについては、docs.python.org の Regular expression operations を参照してください。除外リストをテナントシステムに保存します。

4. 許可リストと除外リストを Keylime ランタイムポリシーに統合します。

   # keylime_create_policy -a <allowlist.txt> -e <excludelist.txt> -o <policy.json>

5. Keylime テナントが設定されているシステムで、keylime_tenant ユーティリティーを使用してエージェントをプロビジョニングします。

   # keylime_tenant -c add -t <agent_ip> -u <agent_uuid> --runtime-policy <policy.json> --cert default

   • <agent_ip> は、エージェントの IP アドレスに置き換えます。
   • <agent_uuid> は、エージェントの UUID に置き換えます。
   • <policy.json> を Keylime ランタイムポリシーファイルへのパスに置き換えます。

   • --cert オプションを使用すると、テナントは、指定されたディレクトリーまたはデフォルトの /var/lib/keylime/ca/ ディレクトリーにある CA 証明書と鍵を使用して、エージェントの証明書を生成し、署名します。ディレクトリーに CA 証明書と鍵が含まれていない場合、テナントは /etc/keylime/ca.conf ファイルの設定に従ってそれらを自動的に生成し、指定されたディレクトリーに保存します。その後、テナントはこれらの鍵と証明書をエージェントに送信します。

     CA 証明書を生成するとき、またはエージェント証明書に署名するとき、次のメッセージが表示され、CA 秘密鍵にアクセスするためのパスワードの入力を求められる場合があります。Please enter the password to decrypt your keystore:

     証明書を使用したくない場合は、代わりに -f オプションを使用してファイルをエージェントに配信します。エージェントをプロビジョニングするには、空のファイルであっても、ファイルを送信する必要があります。

     注記

     Keylime はエージェントに送信されたファイルを暗号化し、エージェントのシステムが TPM ポリシーと IMA 許可リストに準拠している場合にのみ復号化します。デフォルトでは、Keylime は送信された .zip ファイルを展開します。

   たとえば、次のコマンドを使用すると、keylime_tenant は UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000 を持つ新しい Keylime エージェントを 127.0.0.1 にプロビジョニングし、policy.json というランタイムポリシーをロードします。また、デフォルトのディレクトリーに証明書を生成し、その証明書ファイルをエージェントに送信します。Keylime は、/etc/keylime/verifier.conf で設定された TPM ポリシーが満たされている場合にのみ、ファイルを復号化します。

   # keylime_tenant -c add -t 127.0.0.1 -u d432fbb3-d2f1-4a97-9ef7-75bd81c00000 --runtime-policy policy.json --cert default

   注記

   # keylime_tenant -c delete -u <agent_uuid> コマンドを使用して、Keylime によるノードの監視を停止できます。

   keylime_tenant -c update コマンドを使用して、すでに登録されているエージェントの設定を変更できます。

検証

1. オプション: 監視対象のシステムを再起動して、設定が永続的であることを確認します。

2. エージェントのアテステーションが成功することを確認します。

   # keylime_tenant -c cvstatus -u <agent.uuid>
   ...
   {"<agent.uuid>": {"operational_state": "Get Quote"..."attestation_count": 5
   ...

   <agent.uuid> をエージェントの UUID に置き換えます。

   operational_state の値が Get Quote で、attestation_count が 0 以外の場合、このエージェントのアテステーションは成功しています。

   Operational_state の値が Invalid Quote か Failed の場合、アテステーションは失敗し、次のようなコマンド出力が表示されます。

   {"<agent.uuid>": {"operational_state": "Invalid Quote", ... "ima.validation.ima-ng.not_in_allowlist", "attestation_count": 5, "last_received_quote": 1684150329, "last_successful_attestation": 1684150327}}

3. アテステーションが失敗した場合は、verifier ログで詳細を表示します。

   # journalctl -u keylime_verifier
   keylime.tpm - INFO - Checking IMA measurement list...
   keylime.ima - WARNING - File not found in allowlist: /root/bad-script.sh
   keylime.ima - ERROR - IMA ERRORS: template-hash 0 fnf 1 hash 0 good 781
   keylime.cloudverifier - WARNING - agent D432FBB3-D2F1-4A97-9EF7-75BD81C00000 failed, stopping polling

手順

1. Keylime エージェントが設定され実行されている監視対象システムに、create_mb_refstate スクリプトを含む python3-keylime パッケージをインストールします。

   # dnf -y install python3-keylime

2. 監視対象システム上で、create_mb_refstate スクリプトを使用して、システムの現在の状態を測定したブートログからポリシーを生成します。

   # /usr/share/keylime/scripts/create_mb_refstate /sys/kernel/security/tpm0/binary_bios_measurements <./measured_boot_reference_state.json>

   • <./measured_boot_reference_state.json> を、スクリプトが生成されたポリシーを保存するパスに置き換えます。

   • UEFI システムでセキュアブートが有効になっていない場合は、--without-secureboot 引数を渡します。

     重要

     create_mb_refstate スクリプトで生成されるポリシーは、システムの現在の状態に基づいており、非常に厳格です。カーネルの更新やシステムの更新を含め、システムに変更を加えると、ブートプロセスが変更され、システムはアテステーションに失敗します。

3. 生成されたポリシーを、keylime_tenant ユーティリティーが設定されているシステムにコピーします。次に例を示します。

   # scp root@<agent_ip>:<./measured_boot_reference_state.json> <./measured_boot_reference_state.json>

4. Keylime テナントが設定されているシステムで、keylime_tenant ユーティリティーを使用してエージェントをプロビジョニングします。

   # keylime_tenant -c add -t <agent_ip> -u <agent_uuid> --mb_refstate <./measured_boot_reference_state.json> --cert default

   • <agent_ip> は、エージェントの IP アドレスに置き換えます。
   • <agent_uuid> は、エージェントの UUID に置き換えます。
   • <./measured_boot_reference_state.json> を、ブート測定ポリシーへのパスに置き換えます。

   ランタイム監視と一緒にブート測定を設定する場合は、keylime_tenant -c add コマンドを入力するときに両方のユースケースのオプションをすべて指定します。

   注記

   # keylime_tenant -c delete -t <agent_ip> -u <agent_uuid> コマンドを使用して、Keylime によるノードの監視を停止できます。

   keylime_tenant -c update コマンドを使用して、すでに登録されているエージェントの設定を変更できます。

検証

1. 監視対象システムを再起動し、エージェントのアテステーションが成功することを確認します。

   # keylime_tenant -c cvstatus -u <agent_uuid>
   ...
   {"<agent.uuid>": {"operational_state": "Get Quote"..."attestation_count": 5
   ...

   <agent_uuid> は、エージェントの UUID に置き換えます。

   operational_state の値が Get Quote で、attestation_count が 0 以外の場合、このエージェントのアテステーションは成功しています。

   Operational_state の値が Invalid Quote か Failed の場合、アテステーションは失敗し、次のようなコマンド出力が表示されます。

   {"<agent.uuid>": {"operational_state": "Invalid Quote", ... "ima.validation.ima-ng.not_in_allowlist", "attestation_count": 5, "last_received_quote": 1684150329, "last_successful_attestation": 1684150327}}

2. アテステーションが失敗した場合は、verifier ログで詳細を表示します。

   # journalctl -u keylime_verifier
   {"d432fbb3-d2f1-4a97-9ef7-75bd81c00000": {"operational_state": "Tenant Quote Failed", ... "last_event_id": "measured_boot.invalid_pcr_0", "attestation_count": 0, "last_received_quote": 1684487093, "last_successful_attestation": 0}}

手順

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

   # dnf install aide

2. 初期データベースを生成します。

   # aide --init
   Start timestamp: 2024-07-08 10:39:23 -0400 (AIDE 0.16)
   AIDE initialized database at /var/lib/aide/aide.db.new.gz
   
   Number of entries:	55856
   
   ---------------------------------------------------
   The attributes of the (uncompressed) database(s):
   ---------------------------------------------------
   
   /var/lib/aide/aide.db.new.gz
   …
     SHA512   : mZaWoGzL2m6ZcyyZ/AXTIowliEXWSZqx
                IFYImY4f7id4u+Bq8WeuSE2jasZur/A4
                FPBFaBkoCFHdoE/FW/V94Q==

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

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

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

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

手順

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

   # aide --check
   Start timestamp: 2024-07-08 10:43:46 -0400 (AIDE 0.16)
   AIDE found differences between database and filesystem!!
   
   Summary:
     Total number of entries:	55856
     Added entries:		0
     Removed entries:		0
     Changed entries:		1
   
   ---------------------------------------------------
   Changed entries:
   ---------------------------------------------------
   
   f   ...      ..S : /root/.viminfo
   
   ---------------------------------------------------
   Detailed information about changes:
   ---------------------------------------------------
   
   File: /root/.viminfo
     SELinux  : system_u:object_r:admin_home_t:s | unconfined_u:object_r:admin_home
                0                                | _t:s0
   …

2. 少なくとも、AIDE を毎週実行するようにシステムを設定します。最適な設定としては、AIDE を毎日実行します。たとえば、cron コマンドを使用して毎日午前 04:05 に AIDE を実行するようにスケジュールするには、/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/mapper/vg00-lv00

2. LUKS ヘッダーを保存するための空き容量を確認します。シナリオに合わせて、次のいずれかのオプションを使用します。

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

     # lvextend -L+32M /dev/mapper/vg00-lv00

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

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

   # cryptsetup reencrypt --encrypt --init-only --reduce-device-size 32M /dev/mapper/vg00-lv00 lv00_encrypted
   
   /dev/mapper/lv00_encrypted is now active and ready for online encryption.

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

   # mount /dev/mapper/lv00_encrypted /mnt/lv00_encrypted

5. 永続的なマッピングのエントリーを /etc/crypttab ファイルに追加します。

   1. luksUUID を見つけます。

      # cryptsetup luksUUID /dev/mapper/vg00-lv00
      
      a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325

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

      $ vi /etc/crypttab
      
      lv00_encrypted UUID=a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325 none

      a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325 は、デバイスの luksUUID に置き換えます。

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

      $ dracut -f --regenerate-all

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

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

      $ blkid -p /dev/mapper/lv00_encrypted
      
      /dev/mapper/lv00-encrypted: UUID="37bc2492-d8fa-4969-9d9b-bb64d3685aa9" BLOCK_SIZE="4096" TYPE="xfs" USAGE="filesystem"

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

      $ vi /etc/fstab
      
      UUID=37bc2492-d8fa-4969-9d9b-bb64d3685aa9 /home auto rw,user,auto 0

      37bc2492-d8fa-4969-9d9b-bb64d3685aa9 は、ファイルシステムの UUID に置き換えます。

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

   # cryptsetup reencrypt --resume-only /dev/mapper/vg00-lv00
   
   Enter passphrase for /dev/mapper/vg00-lv00:
   Auto-detected active dm device 'lv00_encrypted' for data device /dev/mapper/vg00-lv00.
   Finished, time 00:31.130, 10272 MiB written, speed 330.0 MiB/s

検証

1. 既存のデータが暗号化されているかどうかを確認します。

   # cryptsetup luksDump /dev/mapper/vg00-lv00
   
   LUKS header information
   Version: 2
   Epoch: 4
   Metadata area: 16384 [bytes]
   Keyslots area: 16744448 [bytes]
   UUID: a52e2cc9-a5be-47b8-a95d-6bdf4f2d9325
   Label: (no label)
   Subsystem: (no subsystem)
   Flags: (no flags)
   
   Data segments:
     0: crypt
   	offset: 33554432 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   [...]

2. 暗号化された空のブロックデバイスのステータスを表示します。

   # cryptsetup status lv00_encrypted
   
   /dev/mapper/lv00_encrypted is active and is in use.
     type:    LUKS2
     cipher:  aes-xts-plain64
     keysize: 512 bits
     key location: keyring
     device:  /dev/mapper/vg00-lv00

手順

1. 以下のように、そのデバイスのファイルシステムをすべてアンマウントします。

   # umount /dev/nvme0n1p1

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

   # cryptsetup reencrypt --encrypt --init-only --header /home/header /dev/nvme0n1p1 nvme_encrypted
   
   WARNING!
   ========
   Header file does not exist, do you want to create it?
   
   Are you sure? (Type 'yes' in capital letters): YES
   Enter passphrase for /home/header:
   Verify passphrase:
   /dev/mapper/nvme_encrypted is now active and ready for online encryption.

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

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

   # mount /dev/mapper/nvme_encrypted /mnt/nvme_encrypted

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

   # cryptsetup reencrypt --resume-only --header /home/header /dev/nvme0n1p1
   
   Enter passphrase for /dev/nvme0n1p1:
   Auto-detected active dm device 'nvme_encrypted' for data device /dev/nvme0n1p1.
   Finished, time 00m51s,   10 GiB written, speed 198.2 MiB/s

検証

1. 独立したヘッダーがある LUKS2 を使用するブロックデバイスの既存のデータが暗号化されているかどうかを確認します。

   # cryptsetup luksDump /home/header
   
   LUKS header information
   Version:       	2
   Epoch:         	88
   Metadata area: 	16384 [bytes]
   Keyslots area: 	16744448 [bytes]
   UUID:          	c4f5d274-f4c0-41e3-ac36-22a917ab0386
   Label:         	(no label)
   Subsystem:     	(no subsystem)
   Flags:       	(no flags)
   
   Data segments:
     0: crypt
   	offset: 0 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   	sector: 512 [bytes]
   [...]

2. 暗号化された空のブロックデバイスのステータスを表示します。

   # cryptsetup status nvme_encrypted
   
   /dev/mapper/nvme_encrypted is active and is in use.
     type:    LUKS2
     cipher:  aes-xts-plain64
     keysize: 512 bits
     key location: keyring
     device:  /dev/nvme0n1p1

手順

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

   # cryptsetup luksFormat /dev/nvme0n1p1
   
   WARNING!
   ========
   This will overwrite data on /dev/nvme0n1p1 irrevocably.
   Are you sure? (Type 'yes' in capital letters): YES
   Enter passphrase for /dev/nvme0n1p1:
   Verify passphrase:

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

   # cryptsetup open /dev/nvme0n1p1 nvme0n1p1_encrypted
   
   Enter passphrase for /dev/nvme0n1p1:

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

3. 暗号化されたデータをパーティションに書き込むためのファイルシステムを作成します。このパーティションには、デバイスマップ名を介してアクセスする必要があります。

   # mkfs -t ext4 /dev/mapper/nvme0n1p1_encrypted

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

   # mount /dev/mapper/nvme0n1p1_encrypted mount-point

検証

1. 空のブロックデバイスが暗号化されているかどうかを確認します。

   # cryptsetup luksDump /dev/nvme0n1p1
   
   LUKS header information
   Version:       	2
   Epoch:         	3
   Metadata area: 	16384 [bytes]
   Keyslots area: 	16744448 [bytes]
   UUID:          	34ce4870-ffdf-467c-9a9e-345a53ed8a25
   Label:         	(no label)
   Subsystem:     	(no subsystem)
   Flags:       	(no flags)
   
   Data segments:
     0: crypt
   	offset: 16777216 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   	sector: 512 [bytes]
   [...]

2. 暗号化された空のブロックデバイスのステータスを表示します。

   # cryptsetup status nvme0n1p1_encrypted
   
   /dev/mapper/nvme0n1p1_encrypted is active and is in use.
     type:    LUKS2
     cipher:  aes-xts-plain64
     keysize: 512 bits
     key location: keyring
     device:  /dev/nvme0n1p1
     sector size:  512
     offset:  32768 sectors
     size:    20938752 sectors
     mode:    read/write