보안 강화

절차

1. RHEL 8 웹 콘솔에 로그인합니다.

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

2. 개요 탭에서 시스템 정보 필드를 찾아 하드웨어 세부 정보 보기를 클릭합니다.

3. CPU 보안 행에서 Mitigations 를 클릭합니다.

   이 링크가 없으면 시스템이 SMT를 지원하지 않으므로 취약하지 않습니다.

4. CPU Security Toggles 표에서 Disable concurrent multithreading (nosmt) 옵션을 켭니다.
5. 저장 및 재부팅 버튼을 클릭합니다.

절차

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

절차

1. 시스템을 FIPS 모드로 전환하려면 다음을 수행합니다.

   # fips-mode-setup --enable
   Kernel initramdisks are being regenerated. This might take some time.
   Setting system policy to FIPS
   Note: System-wide crypto policies are applied on application start-up.
   It is recommended to restart the system for the change of policies
   to fully take place.
   FIPS mode will be enabled.
   Please reboot the system for the setting to take effect.

2. 커널이 FIPS 모드로 전환되도록 시스템을 다시 시작하십시오.

   # reboot

절차

1. 선택 사항: 현재 암호화 정책을 표시합니다.

   $ update-crypto-policies --show
   DEFAULT

2. 새 암호화 정책을 설정합니다.

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

   < POLICY >를 설정할 정책 또는 하위 정책(예: FUTURE,LEGACY 또는 FIPS:OSPP )으로 바꿉니다.

3. 시스템을 다시 시작하십시오.

   # reboot

절차

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

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

절차

1. RHEL 8 웹 콘솔에 로그인합니다.

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

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

   

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

   

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

절차

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 )을 생성합니다.

   ---
   - name: Configure cryptographic policies
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure the FUTURE cryptographic security policy on the managed node
         ansible.builtin.include_role:
           name: rhel-system-roles.crypto_policies
         vars:
           - crypto_policies_policy: FUTURE
           - crypto_policies_reboot_ok: true

   예제 플레이북에 지정된 설정은 다음과 같습니다.

   crypto_policies_policy: 미래

   관리 노드에서 필요한 암호화 정책(FUTURE)을 구성합니다. 기본 정책 또는 일부 하위 정책이 있는 기본 정책일 수 있습니다. 지정된 기본 정책 및 하위 정책을 관리 노드에서 사용할 수 있어야 합니다. 기본값은 null 입니다. 즉, 구성이 변경되지 않고 crypto_policies RHEL 시스템 역할은 Ansible 팩트만 수집합니다.

   crypto_policies_reboot_ok: true

   암호화 정책이 변경된 후 시스템이 재부팅되어 모든 서비스와 애플리케이션이 새 구성 파일을 읽습니다. 기본값은 false입니다.

   플레이북에 사용되는 모든 변수에 대한 자세한 내용은 제어 노드의 /usr/share/ansible/roles/rhel-system-roles.crypto_policies/README.md 파일을 참조하십시오.

2. 플레이북 구문을 확인합니다.

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

   이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

3. Playbook을 실행합니다.

   $ ansible-playbook ~/playbook.yml

검증

1. 제어 노드에서 verify_playbook.yml:이라는 다른 플레이북을 생성합니다.

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

   예제 플레이북에 지정된 설정은 다음과 같습니다.

   crypto_policies_active

   crypto_policies_policy 변수에서 수락한 형식으로 현재 활성 정책 이름이 포함된 내보낸 Ansible 팩트입니다.

2. 플레이북 구문을 확인합니다.

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

3. Playbook을 실행합니다.

   $ ansible-playbook ~/verify_playbook.yml
   TASK [debug] **************************
   ok: [host] => {
       "crypto_policies_active": "FUTURE"
   }

   crypto_policies_active 변수는 관리 노드의 활성 정책을 표시합니다.

절차

1. PKCS #11 URI를 포함하여 OpenSC PKCS #11 모듈에서 제공하는 모든 키를 나열하고 출력을 keys.pub 파일에 저장합니다.

   $ ssh-keygen -D pkcs11: > keys.pub

2. 공개 키를 원격 서버로 전송합니다. 이전 단계에서 만든 keys.pub 파일과 함께 ssh-copy-id 명령을 사용합니다.

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

3. ECDSA 키를 사용하여 < ssh-server-example.com >에 연결합니다. 키를 고유하게 참조하는 URI의 하위 집합만 사용할 수 있습니다. 예를 들면 다음과 같습니다.

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

   OpenSSH는 p11-kit-proxy 래퍼를 사용하고 OpenSC PKCS #11 모듈이 p11-kit 툴에 등록되므로 이전 명령을 단순화할 수 있습니다.

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

   PKCS #11 URI의 id= 부분을 건너뛰면 OpenSSH는 proxy 모듈에서 사용할 수 있는 모든 키를 로드합니다. 이렇게 하면 필요한 입력 횟수가 줄어듭니다.

   $ ssh -i pkcs11: <ssh-server-example.com>
   Enter PIN for 'SSH key':
   [ssh-server-example.com] $

4. 선택 사항: ~/.ssh/config 파일에서 동일한 URI 문자열을 사용하여 구성을 영구적으로 만들 수 있습니다.

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

   이제 ssh 클라이언트 유틸리티에서 이 URI와 스마트 카드의 키를 자동으로 사용합니다.

절차

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 <profileID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

   & lt;profileID >를 시스템이 준수해야 하는 프로필 ID로 바꿉니다(예: hipaa ).

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

검증

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

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

   교체:

   • oscap 이 검사 결과를 저장하는 파일 이름이 <scan-report.html >입니다.
   • 시스템이 준수해야 하는 프로파일 ID 가 있는 <profileID>(예: hipaa ).

절차

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

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

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

검증

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

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

   & lt;scan-report.html& gt;을 oscap 이 검사 결과를 저장하는 파일 이름으로 바꿉니다.

절차

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를 찾습니다.

   1. 컨테이너 ID를 찾으려면 podman ps -a 명령을 입력합니다.
   2. 컨테이너 이미지의 ID를 찾으려면 podman images 명령을 입력합니다.

2. 프로필이 있는 컨테이너 또는 컨테이너 이미지의 규정 준수를 평가하고 검사 결과를 파일에 저장합니다.

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

   교체:

   • 컨테이너 또는 컨테이너 이미지의 ID가 있는 <ID>
   • oscap 이 검사 결과를 저장하는 파일 이름이 < scan-report.html >
   • <profileID > 시스템이 준수해야 하는 프로필 ID(예: hipaa,ospp 또는 pci-dss) 사용

절차

1. aide 패키지를 설치합니다.

   # yum install aide

2. 초기 데이터베이스를 생성합니다.

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

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

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

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

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

절차

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

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

2. 최소한 AIDE가 매주 AIDE를 실행하도록 시스템을 구성합니다. 최적으로 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

검증

1. 지정된 사용자 인증 키의 모든 키를 나열합니다.

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

절차

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. RHEL 8 웹 콘솔에 로그인합니다.

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

2. 스토리지를 클릭합니다.
3. 스토리지 테이블에서 암호화할 스토리지 장치 옆에 있는 Cryostat 메뉴 버튼을 클릭합니다.
4. 드롭다운 메뉴에서 형식을 선택합니다.
5. 암호화 필드에서 암호화 사양, LUKS1 또는 LUKS2 를 선택합니다.
6. 새 암호를 설정하고 확인합니다.
7. 선택 사항: 추가 암호화 옵션을 수정합니다.
8. 형식 설정 완료.
9. 형식 을 클릭합니다.

절차

1. RHEL 8 웹 콘솔에 로그인합니다.

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

2. 스토리지를 클릭합니다 .
3. 스토리지 테이블에서 암호화된 데이터가 있는 디스크를 선택합니다.

4. 디스크 페이지에서 Keys 섹션으로 스크롤하여 편집 버튼을 클릭합니다.

   

5. 암호 변경 대화 상자 창에서 다음을 수행합니다.

   1. 현재 암호를 입력합니다.
   2. 새 암호를 입력합니다.

   3. 새 암호를 확인합니다.

      

6. 저장을클릭합니다.

절차

1. 다음 콘텐츠를 사용하여 플레이북 파일(예: ~/playbook.yml )을 생성합니다.

   ---
   - name: Create and configure a volume encrypted with LUKS
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
            - sdb
           fs_type: xfs
           fs_label: label-name
           mount_point: /mnt/data
           encryption: true
           encryption_password: <password>

   encryption_key ,encryption_cipher, encryption_key _size , encryption_ luks 와 같은 다른 암호화 매개변수를 플레이북 파일에 추가할 수도 있습니다.

2. 플레이북 구문을 확인합니다.

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

   이 명령은 구문만 검증하고 잘못되었지만 유효한 구성으로부터 보호하지 않습니다.

3. Playbook을 실행합니다.

   $ ansible-playbook ~/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]
   ...

절차

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 8 웹 콘솔에 로그인합니다.

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

2. 관리 액세스로 전환하고 자격 증명을 제공하고 스토리지를 클릭합니다. 스토리지 테이블에서 잠금 해제를 위해 추가할 암호화된 볼륨이 포함된 디스크를 클릭합니다.

3. 선택한 디스크에 대한 세부 정보가 있는 다음 페이지에서 Keys 섹션에서 + 를 클릭하여 Tang 키를 추가합니다.

   

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

   

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

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

   # tang-show-keys 7500
   x100_1k6GPiDOaMlL3WbpCjHOy9ul1bSfdhI3M08wO0

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

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

검증

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

   

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

   # lsinitrd | grep clevis-luks
   lrwxrwxrwx   1 root     root           48 Jan  4 02:56 etc/systemd/system/cryptsetup.target.wants/clevis-luks-askpass.path -> /usr/lib/systemd/system/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 툴을 사용합니다. RHEL에서 Clevis는 호스트별 구성 옵션 없이 일반 initrd (초기 RAM 디스크)를 생성하고 커널 명령줄에 rd.neednet=1 과 같은 매개변수를 자동으로 추가하지 않습니다. 구성이 초기 부팅 중에 네트워크가 필요한 Tang 핀을 사용하는 경우 --hostonly-cmdline 인수를 사용하고 dracut 은 Tang 바인딩을 감지할 때 rd.neednet=1 을 추가합니다.

   1. clevis-dracut 패키지를 설치합니다.

      # yum install clevis-dracut

   2. 초기 RAM 디스크를 다시 생성합니다.

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

   3. 또는 /etc/dracut.conf.d/ 디렉터리에 .conf 파일을 생성하고 hostonly_cmdline=yes 옵션을 파일에 추가합니다. 그런 다음 --hostonly-cmdline 없이 dracut 을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

      # echo "hostonly_cmdline=yes" > /etc/dracut.conf.d/clevis.conf
      # dracut -fv --regenerate-all

   4. Clevis가 설치된 시스템에서 grubby 툴을 사용하여 초기 부팅 시 Tang 핀의 네트워킹을 사용할 수 있는지 확인할 수도 있습니다.

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

검증

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

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

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

   # lsinitrd | grep clevis-luks
   lrwxrwxrwx   1 root     root           48 Jan  4 02:56 etc/systemd/system/cryptsetup.target.wants/clevis-luks-askpass.path -> /usr/lib/systemd/system/clevis-luks-askpass.path
   …

절차

1. 정적 네트워크 구성을 dracut 명령에서 kernel-cmdline 옵션 값으로 제공할 수 있습니다. 예를 들면 다음과 같습니다.

   # dracut -fv --regenerate-all --kernel-cmdline "ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none nameserver=192.0.2.100"

2. 또는 정적 네트워크 정보를 사용하여 /etc/dracut.conf.d/ 디렉터리에 .conf 파일을 생성한 다음 초기 RAM 디스크 이미지를 다시 생성합니다.

   # cat /etc/dracut.conf.d/static_ip.conf
   kernel_cmdline="ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none nameserver=192.0.2.100"
   # dracut -fv --regenerate-all

절차

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/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 구성과 함께 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. /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