절차

1. 시스템 설치 중에 커널 명령줄에 fips=1 옵션을 추가합니다.
2. 소프트웨어 선택 단계에서는 타사 소프트웨어를 설치하지 마십시오.
3. 설치 후 FIPS 모드에서 시스템이 자동으로 시작됩니다.

절차

1. 시스템 전체 암호화 정책을 LEGACY 수준으로 전환하려면 root로 다음 명령을 입력합니다.

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

절차

1. 웹 콘솔에 로그인합니다. 자세한 내용은 웹 콘솔에 로그인을 참조하십시오.

2. 개요 페이지의 구성 카드에서 policy 옆에 있는 현재 정책 값을 클릭합니다.

   

3. 암호화 정책 변경 대화 상자에서 시스템에서 사용을 시작할 정책을 클릭합니다.

   

4. 적용 및 재부팅 버튼을 클릭합니다.

절차

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. /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. 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. 사용자 지정 정책 파일을 생성합니다.

   # 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. 선택 사항: 플레이북 구문을 확인합니다.

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

3. 인벤토리 파일에서 플레이북을 실행합니다.

   # ansible-playbook -i inventory_file playbook.yml

검증

1. 제어 노드에서 verify_playbook.yml과 같은 다른 플레이북을 생성합니다.

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

   이 플레이북은 시스템의 구성을 변경하지 않고 관리 노드의 활성 정책만 보고합니다.

2. 동일한 인벤토리 파일에서 플레이북을 실행합니다.

   # 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 Kit에 등록되므로 이전 명령을 간소화할 수 있습니다.

   $ 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 웹 브라우저를 열거나 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 hipaa --remediate /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

2. 시스템을 다시 시작합니다.

검증

1. HIPAA 프로파일로 시스템 규정 준수를 평가하고 hipaa_report.html 파일에 검사 결과를 저장합니다.

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

절차

1. Ansible을 사용하여 HIPAA에 맞게 시스템을 교정합니다.

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

2. 시스템을 다시 시작합니다.

검증

1. HIPAA 프로파일로 시스템 규정 준수를 평가하고 hipaa_report.html 파일에 검사 결과를 저장합니다.

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

절차

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 플레이북을 생성합니다.

   # 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. & lt;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 명령에는 루트 권한이 필요하며 컨테이너 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. HIPAA 프로필을 사용하여 컨테이너 이미지의 규정 준수를 평가하고 검사 결과를 report.html HTML 파일에 저장합니다.

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

   보안 준수 여부를 OSPP 또는 PCI-DSS 기준으로 평가하면 096cae65a207 을 컨테이너 이미지의 ID로, hipaa 값을 ospp 또는 pci-dss 로 바꿉니다. oscap-podman 명령에는 root 권한이 필요합니다.

절차

1. Keylime 검증기를 설치합니다.

   # dnf install keylime-verifier

2. 확인자 구성에서 등록 기관 및 검증기의 IP 주소 및 포트를 정의합니다.

   1. /etc/keylime/verifier .conf.d/ 디렉터리에 새 .conf 파일을 만듭니다(예: /etc/keylime/verifier.conf.d/00-verifier-ip.conf ).

      [verifier]
      ip = <verifier_IP_address>

      • & lt;verifier_IP_address& gt;를 검증자의 IP 주소로 바꿉니다. 또는 ip = * 또는 ip = 0.0.0.0 을 사용하여 확인자를 사용 가능한 모든 IP 주소에 바인딩합니다.
      • 선택적으로 port = < verifier_port> 옵션을 사용하여 기본 값 8881 에서 검증자의 포트 를 변경할 수도 있습니다.

   2. /etc/keylime/verifier .conf.d/ 디렉터리에 새 .conf 파일을 만듭니다(예: /etc/keylime/verifier.conf.d/00-registrar-ip.conf ).

      [verifier]
      registrar_ip = <registrar_IP_address>

      • & lt;registrar_IP_address&gt;를 등록 기관의 IP 주소로 바꿉니다.
      • 등록 기관이 기본값 8891 과 다른 포트를 사용하는 경우 registrar_port = < registrar_port> 설정을 추가합니다.

3. 선택 사항: 에이전트 목록에 대해 검증자 데이터베이스를 구성합니다. 기본 구성은 검증자의 /var/lib/keylime/cv_data.sqlite/ 디렉터리의 SQLite 데이터베이스를 사용합니다. /etc/keylime/verifier .conf.d/ 디렉터리에 새 .conf 파일을 생성하여 다른 데이터베이스를 정의할 수 있습니다(예: /etc/keylime/verifier.conf.d/ 00-db-url.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. 검증에 인증서와 키를 추가합니다. Keylime에서 해당 키를 생성하거나 기존 키 및 인증서를 사용하도록 할 수 있습니다.

   • 기본 tls_dir = generate 옵션을 사용하면 Keylime에서 검증자, 등록 기관 및 테넌트에 대한 새 인증서를 /var/lib/keylime/cv_ca/ 디렉터리에 생성합니다.

   • 구성에서 기존 키와 인증서를 로드하려면 확인자 구성에서 해당 위치를 정의합니다.

     참고

     인증서는 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. 검증 서비스를 시작합니다.

   # systemctl enable --now keylime_verifier

   참고

   기본 구성에서 확인자가 다른 Keylime 구성 요소에 대한 CA 및 인증서를 생성하므로 keylime_registrar 서비스를 시작하기 전에 keylime_verifier 를 시작합니다. 사용자 정의 인증서를 사용할 때는 이 순서가 필요하지 않습니다.

절차

1. Keylime 등록 기관을 설치합니다.

   # dnf install keylime-registrar

2. 등록 기관의 IP 주소 및 포트를 정의합니다.

   1. /etc/keylime/registrar .conf.d/ 디렉터리에 새 .conf 파일을 만듭니다(예: /etc/keylime/registrar.conf.d/00-registrar-ip.conf ).

      [registrar]
      ip = <registrar_IP_address>

      • & lt;registrar_IP_address&gt;를 등록 기관의 IP 주소로 바꿉니다. 또는 ip = * 또는 ip = 0.0.0.0 을 사용하여 사용 가능한 모든 IP 주소에 등록 기관을 바인딩합니다.
      • 선택적으로 port = 옵션을 사용하여 Keylime 에이전트가 연결하는 포트를 변경합니다. 기본값은 8890 입니다.
      • 필요한 경우 tls_port = 옵션을 사용하여 Keylime verifier 및 테넌트가 연결하는 TLS 포트를 변경합니다. 기본값은 8891 입니다.

3. 선택 사항: 에이전트 목록에 대한 등록 기관의 데이터베이스를 구성합니다. 기본 구성에서는 등록 기관의 /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. 등록 기관에 인증서 및 키를 추가합니다.

   • 기본 구성을 사용하여 키와 인증서를 /var/lib/keylime/reg_ca/ 디렉터리에 로드할 수 있습니다.

   • 또는 구성에서 키와 인증서의 위치를 정의할 수 있습니다. /etc/keylime/registrar .conf.d/ 디렉터리에 새 .conf 파일을 만듭니다(예: /etc/keylime/registrar.conf.d/ 00-keys-and-certs.conf ).

     중요

     사용자 정의 CA 인증서와 함께 tls_dir = default 설정을 사용하지 마십시오. 대신 인증서 위치 경로를 지정합니다. 자세한 내용은 RHELPLAN-157337 을 참조하십시오.

     [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

   참고

   기본 구성에서 확인자가 다른 Keylime 구성 요소에 대한 CA 및 인증서를 생성하므로 keylime_registrar 서비스를 시작하기 전에 keylime_verifier 를 시작합니다. 사용자 정의 인증서를 사용할 때는 이 순서가 필요하지 않습니다.

절차

1. Keylime 테넌트를 설치합니다.

   # dnf install keylime-tenant

2. /etc/keylime/tenant.conf.d/00-verifier-ip.conf 파일을 편집하여 테넌트의 Keylime 검증기를 정의합니다.

   [tenant]
   verifier_ip = <verifier_ip>

   • & lt;verifier_ip >를 검증자 시스템의 IP 주소로 바꿉니다. 또는 ip = * 또는 ip = 0.0.0.0 을 사용하여 테넌트를 사용 가능한 모든 IP 주소에 바인딩합니다.
   • 검증자가 기본값 8881 과 다른 포트를 사용하는 경우 verifier_port = < verifier_port> 설정을 추가합니다.

3. /etc/keylime/tenant.conf.d/00-registrar-ip.conf 파일을 편집하여 Keylime 등록 기관에 대한 테넌트의 연결을 정의합니다.

   [tenant]
   registrar_ip = <registrar_ip>
   registrar_port = <registrar_port>

   • & lt;registrar_ip >를 등록 기관 시스템의 IP 주소로 바꿉니다.
   • 등록 기관이 기본값 8891 과 다른 포트를 사용하는 경우 registrar_port = < registrar_port> 설정을 추가합니다.

4. 테넌트에 인증서 및 키를 추가합니다.

   1. 기본 구성을 사용하고 키와 인증서를 /var/lib/keylime/cv_ca 디렉터리에 로드할 수 있습니다.

   2. 또는 구성에서 키와 인증서의 위치를 정의할 수 있습니다. /etc/keylime/tenant .conf.d/ 디렉터리에 새 .conf 파일을 만듭니다(예: /etc/keylime/tenant.conf.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 매개변수는 검증자 및 등록 기관 서버 CA 인증서에 대한 경로를 허용합니다. 예를 들어 검증자 및 등록 기관이 다른 CA를 사용하는 경우 쉼표로 구분된 여러 경로를 제공할 수 있습니다.

      참고

      절대 경로를 사용하여 키 및 인증서 위치를 정의합니다. 또는 tls_dir 옵션에 디렉터리를 정의하고 해당 디렉터리에 상대적인 경로를 사용할 수 있습니다.

5. 선택 사항: 신뢰할 수 있는 플랫폼 모듈(TPM) 승인 키(EK)가 /var/lib/keylime/tpm_cert_store 디렉터리의 인증서를 사용하여 확인할 수 없는 경우 해당 디렉터리에 인증서를 추가합니다. 이는 에뮬레이션된 TPM이 있는 가상 머신을 사용할 때 특히 발생할 수 있습니다.

검증

1. 검증의 상태를 확인합니다.

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

   올바르게 설정되고 에이전트가 구성되지 않은 경우 확인자는 기본 에이전트 UUID를 인식하지 못합니다.

2. 등록 기관의 상태를 확인합니다.

   # 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": {}}

   올바르게 설정되고 에이전트가 구성되지 않은 경우 등록 기관은 기본 에이전트 UUID를 인식하지 못합니다.

절차

1. Keylime 에이전트를 설치합니다.

   # dnf install keylime-agent

   이 명령은 keylime-agent-rust 패키지를 설치합니다.

2. 구성 파일에 에이전트의 IP 주소와 포트를 정의합니다. /etc/keylime/agent .conf.d/ 디렉터리에 새 .conf 파일을 만듭니다(예: /etc/keylime/agent.conf.conf.d/00-agent-ip.conf ).

   [agent]
   ip = '<agent_ip>'

   참고

   Keylime 에이전트 구성은 다른 구성 요소의 구성에 사용되는 INI 형식과 다른 TOML 형식을 사용합니다. 따라서 유효한 TOML 구문에 값을 입력합니다(예: 단일 따옴표로 경로 및 여러 경로의 배열은 대괄호로 묶습니다.

   • & lt;agent_IP_address& gt;를 에이전트의 IP 주소로 바꿉니다. 또는 ip = '*' 또는 ip = '0.0.0.0' 을 사용하여 사용 가능한 모든 IP 주소에 에이전트를 바인딩합니다.
   • 선택적으로 port = ' <agent_port> ' 옵션을 사용하여 기본 값 9002 에서 에이전트의 포트 를 변경할 수도 있습니다.

3. 구성 파일에 등록 기관의 IP 주소와 포트를 정의합니다. /etc/keylime/agent .conf.d/ 디렉터리에 새 .conf 파일을 만듭니다(예: /etc/keylime/agent.conf.d/00-registrar-ip.conf ).

   [agent]
   registrar_ip = '<registrar_IP_address>'

   • & lt;registrar_IP_address&gt;를 등록 기관의 IP 주소로 바꿉니다.
   • 선택적으로 registrar_port = ' <registrar_port>' 옵션을 사용하여 기본 값 8890 에서 등록 기관 포트 를 변경할 수도 있습니다.

4. 선택 사항: 에이전트의 UUID(Universally unique identifier)를 정의합니다. 정의되지 않은 경우 기본 UUID가 사용됩니다. /etc/keylime/agent .conf.d/ 디렉터리에 새 .conf 파일을 만듭니다(예: /etc/keylime/agent.conf.conf.d/00-agent-uuid.conf ).

   [agent]
   uuid = '<agent_UUID>'

   • < agent_UUID >를 에이전트의 UUID(예: d432fbb3-d2f1-4a97-9ef7-abcdef012345 )로 바꿉니다. uuidgen 유틸리티를 사용하여 UUID를 생성할 수 있습니다.

5. 선택 사항: 에이전트의 기존 키 및 인증서를 로드합니다. 에이전트에서 no server_key 및 server_cert 를 수신하면 자체 키와 자체 서명된 인증서를 생성합니다.

   중요

   인증서 체인을 사용하지 마십시오. Keylime은 현재 서명 확인 중에 제공된 모든 인증서를 올바르게 사용하지 않으므로 TLS 핸드셰이크에 오류가 발생합니다. 자세한 내용은 RHEL-396 을 참조하십시오.

   구성에서 키와 인증서의 위치를 정의합니다. /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/cert>'
   trusted_client_ca = '[</path/to/ca/cert3>, </path/to/ca/cert4>]'

   참고

   절대 경로를 사용하여 키 및 인증서 위치를 정의합니다. Keylime 에이전트는 상대 경로를 허용하지 않습니다.

6. 방화벽에서 포트를 엽니다.

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

   다른 포트를 사용하는 경우 9002 를 .conf 파일에 정의된 포트 번호로 바꿉니다.

7. keylime_agent 서비스를 활성화하고 시작합니다.

   # systemctl enable --now keylime_agent

8. 선택 사항: Keylime 테넌트가 구성된 시스템에서 에이전트가 올바르게 구성되어 등록 기관에 연결할 수 있는지 확인합니다.

   # 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"}}}

   • & lt;agent_uuid& gt;를 에이전트의 UUID로 바꿉니다.

     등록 기관 및 에이전트가 올바르게 구성된 경우 출력에 에이전트의 IP 주소와 포트가 표시되고 그 뒤에 "operational_state"가 표시됩니다. "Registered".

9. /etc/ima/ima-policy 파일에 다음 내용을 입력하여 새 IMA 정책을 생성합니다.

   # PROC_SUPER_MAGIC
   dont_measure fsmagic=0x9fa0
   # SYSFS_MAGIC
   dont_measure fsmagic=0x62656572
   # DEBUGFS_MAGIC
   dont_measure fsmagic=0x64626720
   # TMPFS_MAGIC
   dont_measure fsmagic=0x01021994
   # RAMFS_MAGIC
   dont_measure fsmagic=0x858458f6
   # SECURITYFS_MAGIC
   dont_measure fsmagic=0x73636673
   # SELINUX_MAGIC
   dont_measure fsmagic=0xf97cff8c
   # CGROUP_SUPER_MAGIC
   dont_measure fsmagic=0x27e0eb
   # OVERLAYFS_MAGIC
   dont_measure fsmagic=0x794c7630
   # Don't measure log, audit or tmp files
   dont_measure obj_type=var_log_t
   dont_measure obj_type=auditd_log_t
   dont_measure obj_type=tmp_t
   # MEASUREMENTS
   measure func=BPRM_CHECK
   measure func=FILE_MMAP mask=MAY_EXEC
   measure func=MODULE_CHECK uid=0

10. 시스템을 재부팅하여 새 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

   & lt;allowlist.txt& gt;를 허용 목록의 파일 이름으로 바꿉니다.

   중요

   SHA-256 해시 함수를 사용합니다. SHA-1은 안전하지 않으며 RHEL 9에서 더 이상 사용되지 않습니다. 자세한 내용은 Red Hat Enterprise Linux 9에서 SHA-1 사용 중단 을 참조하십시오.

2. 생성된 allowlist를 keylime_tenant 유틸리티가 구성된 시스템에 복사합니다. 예를 들면 다음과 같습니다.

   # scp allowlist.txt root@<tenant_._ip>:/root/allowlist.txt

3. 선택 사항: 테넌트 시스템에 파일을 생성하고 제외할 파일과 디렉터리를 입력하여 Keylime 측정에서 제외된 파일 또는 디렉터리 목록을 정의할 수 있습니다. excludelist는 한 줄에 하나의 정규식을 사용하여 Python 정규식을 허용합니다. 자세한 내용은 docs.python.org에서 정규식 작업을 참조하십시오. 예를 들어 /tmp/ 디렉토리에 있는 모든 파일을 Keylime 측정에서 제외하려면 다음 콘텐츠를 사용하여 /root/excludelist.txt 파일을 생성합니다.

   /tmp/.*

   테넌트 시스템에 excludelist를 저장합니다.

4. Keylime 테넌트가 구성된 시스템에서 keylime_tenant 유틸리티를 사용하여 에이전트를 프로비저닝합니다.

   # keylime_tenant -c add -t <agent_ip> -u <agent_uuid> --allowlist <allowlist.txt> --exclude <excludelist> --cert default

   • & lt;agent_ip& gt;를 에이전트의 IP 주소로 바꿉니다.
   • & lt;agent_uuid& gt;를 에이전트의 UUID로 바꿉니다.
   • & lt;allowlist.txt& gt;를 allowlist 파일의 경로로 바꿉니다.
   • excludelist 파일의 경로로 바꿉니다 <excludelist>. --exclude 옵션은 선택 사항입니다. 파일을 전달하지 않고도 에이전트를 프로비저닝할 수 있습니다.

   • --cert 옵션을 사용하면 테넌트에서 지정된 디렉터리 또는 기본 /var/lib/keylime/ca/ 디렉터리에 있는 CA 인증서 및 키를 사용하여 에이전트의 인증서를 생성하고 서명합니다. 디렉터리에 CA 인증서 및 키가 없는 경우 테넌트는 /etc/keylime/ca.conf 파일의 구성에 따라 자동으로 생성하고 지정된 디렉터리에 저장합니다. 그러면 테넌트에서 이러한 키와 인증서를 에이전트에 보냅니다.

     CA 인증서를 생성하거나 에이전트 인증서를 서명할 때 CA 개인 키에 액세스하기 위해 암호를 입력하라는 메시지가 표시될 수 있습니다. 키 저장소의 암호를 해독하려면 암호를 입력하십시오. .

     인증서를 사용하지 않으려면 대신 -f 옵션을 사용하여 에이전트에 파일을 전달합니다. 에이전트를 프로비저닝하려면 빈 파일도 파일을 보내야 합니다.

     참고

     Keylime은 에이전트로 전송된 파일을 암호화하고 에이전트의 시스템이 TPM 정책 및 IMA 허용 목록을 준수하는 경우에만 암호를 해독합니다. 기본적으로 Keylime은 .zip 파일의 압축을 풉니다.

   예를 들어 다음 명령을 사용하여 keylime_tenant 는 127.0.0.1 에 UUID d432fbb3-d2f1-4a97-9ef7-75bd81c00000 을 사용하여 새 Keylime 에이전트를 프로비저닝하고 allowlist.txt 라는 허용 목록을 로드합니다. 또한 인증서를 기본 디렉터리에 생성하여 에이전트로 보냅니다. Keylime는 /etc/keylime/verifier.conf 에 구성된 TPM 정책이 충족되는 경우에만 파일의 암호를 해독합니다.

   # keylime_tenant -c add -t 127.0.0.1 -u d432fbb3-d2f1-4a97-9ef7-75bd81c00000 -cert default --allowlist allowlist.txt --exclude excludelist.txt

   참고

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

   & lt;agent.uuid& gt;를 에이전트의 UUID로 바꿉니다.

   operational_state 값이 Get Quote 이고 attestation_count 가 0이 아닌 경우 이 에이전트의 인증이 성공적으로 수행됩니다.

   operational_state 값이 Invalid Quote 또는 Failed attestation에 실패하면 명령과 유사한 출력이 표시됩니다.

   {"<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. 테스트에 실패하면 검증기 로그에 세부 정보를 표시합니다.

   # 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 >을 바꿉니다.

   중요

   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>

   • & lt;agent_ip& gt;를 에이전트의 IP 주소로 바꿉니다.
   • & lt;agent_uuid& gt;를 에이전트의 UUID로 바꿉니다.
   • & lt;./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
   ...

   & lt;agent_uuid& gt;를 에이전트의 UUID로 바꿉니다.

   operational_state 값이 Get Quote 이고 attestation_count 가 0이 아닌 경우 이 에이전트의 인증이 성공적으로 수행됩니다.

   operational_state 값이 Invalid Quote 또는 Failed attestation에 실패하면 명령과 유사한 출력이 표시됩니다.

   {"<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. 테스트에 실패하면 검증기 로그에 세부 정보를 표시합니다.

   # 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

   참고

   기본 구성에서 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를 매일 실행합니다. 예를 들어 cron 명령을 사용하여 매일 AIDE 실행을 04:05 a.m로 예약하려면 /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 와 같은 파티션 관리 도구를 사용하여 파티션을 확장하십시오.
   • 장치의 파일 시스템을 축소합니다. ext 2, 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

절차

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

   playbook.yml 파일의 encryption_key,encryption_cipher,encryption_key_size, encryption_luks 버전과 같은 다른 암호화 매개변수도 추가할 수 있습니다.

2. 선택 사항: 플레이북 구문을 확인합니다.

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

3. 인벤토리 파일에서 플레이북을 실행합니다.

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

검증

1. 암호화 상태를 확인합니다.

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

2. 생성된 LUKS 암호화된 볼륨을 확인합니다.

   # cryptsetup luksDump /dev/sdb
   
   Version:       	2
   Epoch:         	6
   Metadata area: 	16384 [bytes]
   Keyslots area: 	33521664 [bytes]
   UUID:          	a4c6be82-7347-4a91-a8ad-9479b72c9426
   Label:         	(no label)
   Subsystem:     	(no subsystem)
   Flags:       	allow-discards
   
   Data segments:
     0: crypt
   	offset: 33554432 [bytes]
   	length: (whole device)
   	cipher: aes-xts-plain64
   	sector: 4096 [bytes]
   [...]

3. 스토리지 역할이 지원하는 playbook.yml 파일에서 cryptsetup 매개변수를 확인합니다.

   # cat ~/playbook.yml
   
       - hosts: all
         vars:
           storage_volumes:
             - name: foo
               type: disk
               disks:
                - nvme0n1
               fs_type: xfs
               fs_label: label-name
               mount_point: /mnt/data
               encryption: true
               #encryption_password: passwdpasswd
               encryption_key: /home/passwd_key
               encryption_cipher: aes-xts-plain64
               encryption_key_size: 512
               encryption_luks_version: luks2
   
         roles:
          - rhel-system-roles.storage

절차

1. 암호화된 볼륨이 있는 시스템에 Clevis 및 해당 핀을 설치하려면 다음을 수행합니다.

   # dnf install clevis

2. 데이터의 암호를 해독하려면 clevis decrypt 명령을 사용하고 JSON Web Encryption(JWE) 형식의 암호화 텍스트를 제공합니다. 예를 들면 다음과 같습니다.

   $ clevis decrypt < secret.jwe

절차

1. tang 패키지 및 해당 종속 항목을 설치하려면 root로 다음 명령을 입력합니다.

   # dnf install tang

2. (예: 7500/tcp ) .occupied 포트를 선택하고 tangd 서비스가 해당 포트에 바인딩되도록 허용합니다.

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

   포트는 한 번에 하나의 서비스에서만 사용할 수 있으므로 이미 사용되고 있는 포트를 사용하려는 경우 ValueError를 의미합니다. 포트가 이미 정의된 오류 메시지입니다.

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. Ctrl+O 누른 후 를 입력하여 변경 사항을 저장합니다. Ctrl+X 를 눌러 편집기를 종료합니다.

8. 변경된 구성을 다시 로드합니다.

   # systemctl daemon-reload

9. 구성이 작동하는지 확인합니다.

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

10. 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. EgressIP 클라이언트에서 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. 웹 브라우저에 다음 주소를 입력하여 RHEL 웹 콘솔을 엽니다.

   https://<localhost>:9090

   원격 시스템에 연결할 때 < localhost > 부분을 원격 서버의 호스트 이름 또는 IP 주소로 바꿉니다.

2. 인증 정보를 제공하고 스토리지를 클릭합니다. Filesystems 섹션에서 잠금 해제를 위해 추가할 암호화된 볼륨이 포함된 디스크를 클릭합니다.
3. 선택한 디스크의 파티션 및 드라이브 세부 정보를 나열하는 다음 창에서 암호화된 파일 시스템 옆에 있는 >을 클릭하여 Tang 서버를 사용하여 잠금 해제하려는 암호화된 볼륨의 세부 정보를 확장하고 암호화를 클릭합니다.

4. 키 섹션에서 +를 클릭하여 Tang 키를 추가합니다.

   

5. Tang 키 서버 를 키 소스로 선택하고 Tang 서버의 주소 및 LUKS 암호화 장치를 잠금 해제하는 암호를 제공합니다. 추가를 클릭하여 확인합니다.

   

   다음 대화 상자 창에서 키 해시가 일치하는지 확인하는 명령을 제공합니다.

6. Tang 서버의 터미널에서 tang-show-keys 명령을 사용하여 비교할 키 해시를 표시합니다. 이 예에서 Tang 서버는 포트 7500에서 실행되고 있습니다.

   # tang-show-keys 7500
   fM-EwYeiTxS66X3s1UAywsGKGnxnpll8ig0KOQmr9CM

7. 웹 콘솔의 키 해시와 이전에 나열된 명령의 출력에서와 이전에 나열된 명령의 출력에서 신뢰 키를 클릭하면 신뢰 키를 클릭합니다.

   
8. RHEL 9.2 이상에서는 암호화된 루트 파일 시스템 및 Tang 서버를 선택한 후 커널 명령줄에 rd.neednet=1 매개변수 추가를 건너뛰고 clevis-dracut 패키지를 설치하고 초기 램디스크(initrd)를 다시 생성할 수 있습니다. 루트가 아닌 파일 시스템의 경우 웹 콘솔에서 remote-cryptsetup.target 및 clevis-luks-akspass.path systemd 장치를 활성화하고 clevis-systemd 패키지를 설치하고 _netdev 매개 변수를 fstab 및 crypttab 구성 파일에 추가합니다.

검증

1. 새로 추가된 Tang 키가 Keyserver 유형의 Keys 섹션에 나열되어 있는지 확인합니다.

   

2. 초기 부팅에 바인딩을 사용할 수 있는지 확인합니다. 예를 들면 다음과 같습니다.

   # lsinitrd | grep clevis
   clevis
   clevis-pin-null
   clevis-pin-sss
   clevis-pin-tang
   clevis-pin-tpm2
   lrwxrwxrwx   1 root     root           48 Feb 14 17:45 etc/systemd/system/cryptsetup.target.wants/clevis-luks-askpass.path…
   …

절차

1. 기존 LUKS 암호화된 볼륨의 잠금을 자동으로 해제하려면 clevis-luks 하위 패키지를 설치합니다.

   # dnf 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:

   이 명령은 다음 네 가지 단계를 수행합니다.

   1. LUKS 마스터 키와 동일한 엔트로피를 사용하여 새 키를 만듭니다.
   2. Clevis를 사용하여 새 키를 암호화합니다.
   3. LUKS2 헤더에 Clevis JWE 오브젝트를 저장하거나 기본이 아닌 LUKS1 헤더가 사용되는 경우 LUKSMeta를 사용합니다.
   4. LUKS에 사용할 새 키를 활성화합니다.
   참고

   바인딩 절차에서는 사용 가능한 LUKS 암호 슬롯이 하나 이상 있다고 가정합니다. clevis luks bind 명령은 슬롯 중 하나를 사용합니다.

   이제 Clevis 정책과 함께 기존 암호를 사용하여 볼륨을 잠금 해제할 수 있습니다.

4. 초기 부팅 시스템이 디스크 바인딩을 처리할 수 있도록 하려면 이미 설치된 시스템에서 dracut 툴을 사용합니다.

   # dnf install clevis-dracut

   RHEL에서 Clevis는 호스트별 구성 옵션 없이 일반 initrd (초기 RAM 디스크)를 생성하고 커널 명령줄에 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 하위 패키지를 설치합니다.

   # dnf 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:

   이 명령은 다음 네 가지 단계를 수행합니다.

   1. LUKS 마스터 키와 동일한 엔트로피를 사용하여 새 키를 만듭니다.
   2. Clevis를 사용하여 새 키를 암호화합니다.
   3. LUKS2 헤더에 Clevis JWE 오브젝트를 저장하거나 기본이 아닌 LUKS1 헤더가 사용되는 경우 LUKSMeta를 사용합니다.

   4. LUKS에 사용할 새 키를 활성화합니다.

      참고

      바인딩 절차에서는 사용 가능한 LUKS 암호 슬롯이 하나 이상 있다고 가정합니다. clevis luks bind 명령은 슬롯 중 하나를 사용합니다.

      또는 데이터를 특정 플랫폼 구성 등록 (PCR) 상태로 전환하려는 경우 pcr_bank 및 pcr_ids 값을 clevis luks bind 명령에 추가합니다.

      # 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의 단계에 따라 LUKS 장치의 암호를 해독 하지 않습니다.

4. 이제 Clevis 정책과 함께 기존 암호를 사용하여 볼륨을 잠금 해제할 수 있습니다.

5. 초기 부팅 시스템이 디스크 바인딩을 처리할 수 있도록 하려면 이미 설치된 시스템에서 dracut 툴을 사용합니다.

   # dnf 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에 의해 암호화된 경우 Version으로 표시됩니다. 1 string in the output of the cryptsetup luksDump 명령 출력의 문자열 luksmeta wipe 명령을 사용하여 다음 추가 단계를 수행합니다.

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

4. Clevis 암호가 포함된 키 슬롯을 지웁니다.

   # cryptsetup luksKillSlot /dev/sda2 1

절차

1. Kickstart에 임시 암호로 /boot 이외의 모든 마운트 지점에 대해 LUKS 암호화가 활성화되도록 디스크를 파티션하도록 지시합니다. 암호는 이 등록 프로세스 단계에서 임시적입니다.

   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. %packages 섹션에 나열하여 관련 Clevis 패키지를 설치합니다.

   %packages
   clevis-dracut
   clevis-luks
   clevis-systemd
   %end

3. 필요한 경우 암호화된 볼륨을 수동으로 잠금 해제하려면 임시 암호를 제거하기 전에 강력한 암호를 추가합니다. 자세한 내용은 기존 LUKS 장치에 암호, 키 또는 키 파일을 추가하는 방법 문서를 참조하십시오.

4. %post 섹션에서 바인딩을 수행하기 위해 clevis luks bind를 호출합니다. 임시 암호를 삭제합니다.

   %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 클라이언트를 사용하는 경우 LUKS 암호화 볼륨의 수동 등록 구성에 설명된 대로 dracut 명령을 수정해야 합니다.

   RHEL 8.3에서 clevis luks bind 명령의 -y 옵션을 사용할 수 있습니다. RHEL 8.2 이상에서는 -y 를 clevis luks bind 명령에서 -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 패키지를 설치합니다.

   # dnf install clevis-udisks2

2. 시스템을 재부팅한 다음 LUKS 암호화 볼륨의 수동 등록 구성에 설명된 대로 clevis luks bind 명령을 사용하여 바인딩 단계를 수행합니다. 예를 들면 다음과 같습니다.

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

3. 이제 GNOME 데스크탑 세션에서 LUKS로 암호화된 이동식 장치의 잠금을 자동으로 해제할 수 있습니다. Clevis 정책에 바인딩된 장치는 clevis luks unlock 명령으로 잠금 해제할 수도 있습니다.

   # clevis luks unlock -d /dev/sdb1

절차

1. registry.redhat.io 레지스트리에서 tang 컨테이너 이미지를 가져옵니다.

   # podman pull registry.redhat.io/rhel9/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/rhel9/tang

   Tang은 기본적으로 포트 80을 사용하지만 이는 Apache HTTP 서버와 같은 다른 서비스와 충돌할 수 있습니다.

3. [선택 사항] 보안을 강화하기 위해 Tang 키를 주기적으로 회전합니다. tangd-rotate-keys 스크립트를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

   # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel9/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 서버에 대한 설정이 포함된 플레이북을 준비합니다. 처음부터 시작하거나 /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/ 디렉터리의 예제 플레이북 중 하나를 사용할 수 있습니다.

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

2. 선택한 텍스트 편집기에서 플레이북을 편집합니다. 예를 들면 다음과 같습니다.

   # vi my-tang-playbook.yml

3. 필수 매개 변수를 추가합니다. 다음 예제 플레이북은 Tang 서버와 키 교체의 배포를 확인합니다.

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

   참고

   nbde_server_manage_firewall 및 nbde_server_manage_selinux 가 모두 true 로 설정되므로 nbde_server 역할은 firewall 및 selinux 역할을 사용하여 nbde_server 역할에서 사용하는 포트를 관리합니다.

4. 완료된 플레이북을 적용합니다.

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

   다음과 같습니다.

   • inventory-file 은 인벤토리 파일입니다.
   • logging-playbook.yml 은 사용하는 플레이북입니다.

절차

1. Clevis 클라이언트에 대한 설정을 포함하는 플레이북을 준비합니다. 처음부터 시작하거나 /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/ 디렉터리의 예제 플레이북 중 하나를 사용할 수 있습니다.

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

2. 선택한 텍스트 편집기에서 플레이북을 편집합니다. 예를 들면 다음과 같습니다.

   # vi my-clevis-playbook.yml

3. 필수 매개 변수를 추가합니다. 다음 예제 플레이북은 두 개 이상의 Tang 서버 중 하나를 사용할 수 있는 경우 에서 두 개의 LUKS 암호화 볼륨의 잠금 해제를 자동화하도록 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. 완료된 플레이북을 적용합니다.

   # 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. 프로그램에서 adjtimex 또는 settimeofday 시스템 호출이 사용될 때마다 로그 항목을 생성하는 규칙을 정의하기 위해 64비트 아키텍처를 사용합니다.

   # 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. /usr/share/audit/sample-rules/ 디렉토리에서 사전 구성된 규칙 파일 44-installers.rules 를 /etc/audit/rules.d/ 디렉터리에 복사합니다.

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

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. 설치를 수행합니다. 예를 들면 다음과 같습니다.

   # dnf reinstall -y vim-enhanced

3. 최근 설치 이벤트의 감사 로그를 검색합니다. 예를 들면 다음과 같습니다.

   # 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 패키지를 설치합니다.

   # dnf 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