절차

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. DEFAULT 시스템 전체 암호화 정책 수준에 정책 조정을 적용합니다.

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

2. 이미 실행 중인 서비스 및 애플리케이션에 암호화 설정을 적용하려면 시스템을 다시 시작하십시오.

   # reboot

절차

1. 사용자 지정 정책 파일을 생성합니다.

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

   또는 사전 정의된 4가지 정책 수준 중 하나를 복사하여 시작합니다.

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

2. 다음과 같은 요구 사항에 맞게 선택한 텍스트 편집기에서 사용자 지정 암호화 정책으로 파일을 편집합니다.

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

3. 시스템 전체 암호화 정책을 사용자 지정 수준으로 전환합니다.

   # update-crypto-policies --set MYPOLICY

4. 이미 실행 중인 서비스 및 애플리케이션에 암호화 설정을 적용하려면 시스템을 다시 시작하십시오.

   # reboot

절차

1. 다음 내용으로 새 playbook.yml 파일을 생성합니다.

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

   예를 들어 FUTURE 값을 선호하는 암호화 정책으로 교체할 수 있습니다. DEFAULT,LEGACY 및 FIPS:OSPP.

   crypto_policies_reboot_ok: true 변수를 사용하면 시스템 역할에서 암호화 정책을 변경한 후 시스템이 재부팅됩니다.

   자세한 내용은 crypto_policies 시스템 역할 변수 및 팩트 를 참조하십시오.

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

   # 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-rhel8-ds.xml

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

검증

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

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

절차

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

   # ansible-playbook -i localhost, -c local /usr/share/scap-security-guide/ansible/rhel8-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-rhel8-ds.xml

절차

1. 시스템을 스캔하고 결과를 저장합니다.

   # oscap xccdf eval --profile hipaa --results <hipaa-results.xml> /usr/share/xml/scap/ssg/content/ssg-rhel8-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-rhel8-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/RHEL8/rhel-8.oval.xml.bz2 | bzip2 --decompress > rhel-8.oval.xml

2. 컨테이너 또는 컨테이너 이미지의 ID를 가져옵니다. 예를 들면 다음과 같습니다.

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

3. 컨테이너 또는 컨테이너 이미지에서 취약점을 검사하고 결과를 vulnerability.html 파일에 저장합니다.

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

   oscap-podman 명령에는 루트 권한이 필요하며 컨테이너 ID는 첫 번째 인수입니다.

절차

1. 컨테이너 또는 컨테이너 이미지의 ID를 가져옵니다. 예를 들면 다음과 같습니다.

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

2. HIPAA 프로필을 사용하여 컨테이너 이미지의 규정 준수를 평가하고 검사 결과를 report.html HTML 파일에 저장합니다.

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

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

절차

1. aide 패키지를 설치하려면 다음을 수행합니다.

   # yum install aide

2. 초기 데이터베이스를 생성하려면 다음을 수행합니다.

   # aide --init

   참고

   기본 구성에서 aide --init 명령은 /etc/aide.conf 파일에 정의된 디렉토리와 파일 집합만 확인합니다. AIDE 데이터베이스에 추가 디렉토리나 파일을 포함하고 감시된 매개 변수를 변경하려면 그에 따라 /etc/aide.conf 를 편집합니다.

3. 데이터베이스 사용을 시작하려면 초기 데이터베이스 파일 이름에서 .new 하위 문자열을 제거합니다.

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

4. AIDE 데이터베이스의 위치를 변경하려면 /etc/aide.conf 파일을 편집하고 DBDIR 값을 수정합니다. 보안을 강화하기 위해 데이터베이스, 구성 및 /usr/sbin/aide 바이너리 파일을 읽기 전용 미디어와 같은 보안 위치에 저장하십시오.

절차

1. 수동 검사를 시작하려면 다음을 수행합니다.

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

2. 최소한 AIDE가 매주 AIDE를 실행하도록 시스템을 구성합니다. 최적으로 AIDE를 매일 실행합니다. 예를 들어 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. 다음 유틸리티 중 하나를 사용하여 영구 처리(예: 81000001 )가 있는 SHA-256 기본 스토리지 키로 2048비트 RSA 키를 생성합니다.

   1. tss2 패키지를 사용하여 다음을 수행합니다.

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

   2. tpm2-tools 패키지를 사용하여 다음을 수행합니다.

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

2. 신뢰할 수 있는 키를 생성합니다.

   1. keyctl 구문으로 TPM 2.0을 사용하면 trusted < NAME > "new < KEY_LENGTH > keyhandle= <PERSISTENT-HANDLE > [options]" < KEYRING > . 이 예에서 영구 처리는 81000001 입니다.

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

      이 명령은 32 바이트(256비트) 길이로 kmk 라는 신뢰할 수 있는 키를 생성하여 사용자 인증 키(@u)에 배치합니다. 키는 32~128바이트(256비트에서 1024비트)의 길이를 가질 수 있습니다.

   2. keyctl 구문으로 TPM 1.2를 사용하면 신뢰할 수 있는 < NAME > "new <KEY_LENGTH>" <KEYRING > :

      # keyctl add trusted kmk "new 32" @u

3. 커널 인증 키의 현재 구조를 나열합니다.

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

4. 신뢰할 수 있는 키의 일련 번호를 사용하여 사용자 공간 Blob으로 키를 내보냅니다.

   # keyctl pipe 642500861 > kmk.blob

   명령은 pipe 하위 명령과 kmk 의 일련 번호를 사용합니다.

5. 사용자 공간 Blob에서 신뢰할 수 있는 키를 로드합니다.

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

6. TPM-sealed 신뢰할 수 있는 키(kmk)를 사용하는 안전한 암호화된 키를 만듭니다. 다음 구문을 따르십시오. keyctl add encrypted <NAME> "new [FORMAT] <KEY_TYPE>:<PRI Cryostat_KEY_NAME> <KEY_LENGTH>" <KEYRING > :

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

절차

1. 임의의 숫자 시퀀스를 사용하여 사용자 키를 생성합니다.

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

   명령은 기본 키 역할을 하고 실제 암호화된 키를 봉인하는 데 사용되는 kmk-user 라는 사용자 키를 생성합니다.

2. 이전 단계의 기본 키를 사용하여 암호화된 키를 생성합니다.

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

3. 선택적으로 지정된 사용자 인증 키의 모든 키를 나열합니다.

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

절차

1. 현재 부팅 항목에 대한 수정 모드에서 IMA 및 EVM을 활성화하고 사용자가 다음 커널 명령줄 매개변수를 추가하여 IMA 측정값을 수집하고 업데이트할 수 있습니다.

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

   이 명령을 사용하면 현재 부팅 항목에 대한 수정 모드에서 IMA 및 EVM을 활성화하고 사용자가 IMA 측정값을 수집하고 업데이트할 수 있습니다.

   ima_policy=appraise_tcb 커널 명령줄 매개 변수를 사용하면 커널이 기본 trusted Computing Base(ECDHEB) 측정 정책 및 평가 단계를 사용합니다. 평가 단계는 이전 및 현재 측정값이 일치하지 않는 파일에 대한 액세스를 금지합니다.

2. 재부팅하여 변경 사항을 적용합니다.

3. 선택 사항: 매개변수가 커널 명령줄에 추가되었는지 확인합니다.

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

4. 커널 마스터 키를 생성하여 EVM 키를 보호합니다.

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

   kmk 는 커널 공간 메모리에 전적으로 유지됩니다. kmk 의 32바이트 긴 값은 /dev/urandom 파일에서 임의의 바이트에서 생성되고 사용자(@u) 인증 키에 배치됩니다. 키 일련 번호는 이전 출력의 첫 번째 행에 있습니다.

5. kmk 를 기반으로 암호화된 EVM 키를 만듭니다.

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

   명령은 kmk 를 사용하여 64바이트 긴 사용자 키( evm-key)를 생성하고 암호화하여 사용자(@u) 인증 키에 배치합니다. 키 일련 번호는 이전 출력의 첫 번째 행에 있습니다.

   중요

   이 이름은 EVM 하위 시스템 이름이 필요하며 작업 중이므로 사용자 키의 이름을 evm-key 로 지정해야 합니다.

6. 내보낸 키에 사용할 디렉토리를 생성합니다.

   # mkdir -p /etc/keys/

7. kmk 를 검색하고 암호화되지 않은 값을 새 디렉터리로 내보냅니다.

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

8. evm-key 를 검색하고 암호화된 값을 새 디렉터리로 내보냅니다.

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

   evm-key 는 이전에 커널 마스터 키로 암호화되었습니다.

9. 선택 사항: 새로 생성된 키를 확인합니다.

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

10. 선택 사항: 예를 들어 시스템을 재부팅한 후 인증 키에서 키가 제거된 경우 새 키를 생성하는 대신 이미 내보낸 kmk 및 evm-key 를 가져올 수 있습니다.

    1. kmk 를 가져옵니다.

       # keyctl add user kmk "$(cat /etc/keys/kmk)" @u
       451342217

    2. evm-key 를 가져옵니다.

       # keyctl add encrypted evm-key "load $(cat /etc/keys/evm-key)" @u
       924537557

11. EVM을 활성화합니다.

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

12. 전체 시스템의 레이블을 다시 지정합니다.

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

    주의

    시스템의 레이블을 다시 지정하지 않고 IMA 및 EVM을 활성화하면 시스템의 대부분의 파일에 액세스할 수 없게 될 수 있습니다.

절차

1. 테스트 파일을 생성합니다.

   # echo <Test_text> > test_file

   IMA 및 EVM은 test_file 예제 파일에 확장 속성으로 저장된 해시 값을 할당했는지 확인합니다.

2. 파일의 확장 속성을 검사합니다.

   # getfattr -m . -d test_file
   # file: test_file
   security.evm=0sAnDIy4VPA0HArpPO/EqiutnNyBql
   security.ima=0sAQOEDeuUnWzwwKYk+n66h/vby3eD

   예제 출력에는 IMA 및 EVM 해시 값과 SELinux 컨텍스트가 포함된 확장된 속성이 표시되어 있습니다. EVM은 다른 속성과 관련된 security.evm 확장 속성을 추가합니다. 이 시점에서 security.evm 에서 evmctl 유틸리티를 사용하여 RSA 기반 디지털 서명 또는 HMAC-SHA1( Hash-based Message Authentication Code)을 생성할 수 있습니다.

절차

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 및 해당 핀을 설치하려면 다음을 수행합니다.

   # yum install clevis

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

   $ clevis decrypt < secret.jwe

절차

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

   # yum 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 8.8 이상에서는 암호화된 루트 파일 시스템 및 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 하위 패키지를 설치합니다.

   # yum install clevis-luks

2. PBD의 LUKS 암호화 볼륨을 식별합니다. 다음 예에서 블록 장치는 /dev/sda2 라고 합니다.

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

3. clevis luks bind 명령을 사용하여 볼륨을 Tang 서버에 바인딩합니다.

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

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

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

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

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

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

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

   # yum install clevis-luks

2. PBD의 LUKS 암호화 볼륨을 식별합니다. 다음 예에서 블록 장치는 /dev/sda2 라고 합니다.

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

3. clevis luks bind 명령을 사용하여 TPM 2.0 장치에 볼륨을 바인딩합니다. 예를 들면 다음과 같습니다.

   # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa"}'
   ...
   Do you wish to initialize /dev/sda2? [yn] y
   Enter existing LUKS password:

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

   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 툴을 사용합니다.

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

검증

1. Clevis JWE 오브젝트가 LUKS 헤더에 성공적으로 배치되었는지 확인하려면 clevis luks list 명령을 사용합니다.

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

절차

1. 볼륨(예: /dev/sda 2)이 암호화된 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 구성과 함께 EgressIP 클라이언트를 사용하는 경우 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 패키지를 설치합니다.

   # yum 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/rhel8/tang

2. 컨테이너를 실행하고 해당 포트를 지정하고 Tang 키의 경로를 지정합니다. 이전 예제에서는 tang 컨테이너를 실행하고 포트 7500을 지정하고 /var/db/tang 디렉터리의 Tang 키의 경로를 나타냅니다.

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

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

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

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

절차

1. Tang 서버에 대한 설정이 포함된 플레이북을 준비합니다. 처음부터 시작하거나 /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 파일의 모든 쓰기 액세스 권한을 로깅하는 규칙을 정의하기 위해 /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 또는 settimeofofday 시스템 호출이 프로그램에서 사용될 때마다 로그 항목을 생성하는 규칙을 정의하기 위해 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. RHEL 8.6 이상에서 /usr/share/audit/sample-rules/ 디렉터리에서 /etc/audit/rules.d/ 디렉터리에 사전 구성된 규칙 파일 44-installers.rules 를 복사합니다.

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

   RHEL 8.5 및 이전 버전에서 44-installers.rules 라는 /etc/audit/rules.d/ 디렉터리에 새 파일을 생성하고 다음 규칙을 삽입합니다.

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

   동일한 구문을 사용하여 소프트웨어를 설치하는 다른 유틸리티에 대한 규칙을 추가할 수 있습니다(예: pip 및 npm ).

2. 감사 규칙을 로드합니다.

   # augenrules --load

검증

1. 로드된 규칙을 나열합니다.

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

2. 설치를 수행합니다. 예를 들면 다음과 같습니다.

   # yum reinstall -y vim-enhanced

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

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