4.2. RHEL 8에서 TLS의 보안 고려 사항
RHEL 8에서는 시스템 전체 암호화 정책 때문에 암호화 관련 고려 사항이 크게 단순화됩니다. DEFAULT 암호화 정책은 TLS 1.2 및 1.3만 허용합니다. 시스템이 이전 버전의 TLS를 사용하여 연결을 협상할 수 있도록 하려면 애플리케이션에서 다음과 같은 암호화 정책을 선택하거나 update-crypto-policies 명령을 사용하여 LEGACY 정책으로 전환해야 합니다. 자세한 내용은 시스템 전체 암호화 정책 사용을 참조하십시오.
RHEL 8에 포함된 라이브러리에서 제공하는 기본 설정은 대부분의 배포에 충분히 안전합니다. TLS 구현에서는 가능한 경우 또는 기존 클라이언트 또는 서버의 연결을 방지할 수 없는 보안 알고리즘을 사용합니다. 보안 알고리즘 또는 프로토콜을 지원하지 않는 레거시 클라이언트나 서버가 연결되지 않거나 연결할 수 없는 엄격한 보안 요구 사항을 충족하는 환경에서 강화된 설정을 적용합니다.
TLS 구성을 강화하는 가장 간단한 방법은 update-crypto-policies --set FUTURE 명령을 사용하여 시스템 전체 암호화 정책 수준을 FUTURE로 전환하는 것입니다.
LEGACY 암호화 정책에 대해 비활성화된 알고리즘은 RHEL 8 보안에 대한 Red Hat의 비전을 따르지 않으며 보안 속성은 신뢰할 수 없습니다. 다시 활성화하는 대신 이러한 알고리즘 사용에서 벗어나는 것이 좋습니다. 예를 들어 이전 하드웨어와의 상호 운용성을 위해 다시 활성화하기로 결정한 경우, 이를 안전하지 않은 것으로 처리하고 네트워크 상호 작용을 별도의 네트워크 세그먼트에 격리하는 등의 추가 보호 조치를 적용합니다. 공용 네트워크에서 사용하지 마십시오.
RHEL 시스템 전체 암호화 정책을 따르거나 설정에 맞는 사용자 지정 암호화 정책을 생성하기로 결정한 경우 사용자 정의 구성에서 선호하는 프로토콜, 암호화 제품군 및 키 길이에 다음 권장 사항을 사용하십시오.
4.2.1. 프로토콜
최신 버전의 TLS는 최상의 보안 메커니즘을 제공합니다. 이전 버전의 TLS에 대한 지원을 포함하는 강력한 이유가 없으면 시스템에서 최소 TLS 버전 1.2를 사용하여 연결을 협상할 수 있습니다.
RHEL 8은 TLS 버전 1.3을 지원하더라도 이 프로토콜의 일부 기능은 RHEL 8 구성 요소에서 완전히 지원되지는 않습니다. 예를 들어 연결 대기 시간을 줄이는 0-RTT(round Trip Time) 기능은 Apache 웹 서버에서 아직 완전히 지원하지 않습니다.
4.2.2. 암호화 제품군
최신의 더욱 안전한 암호화 제품군은 보안이 떨어지는 오래된 제품군보다 선호되어야 합니다. 항상 암호화 또는 인증을 전혀 제공하지 않는 eNULL 및 aNULL 암호화 제품군 사용을 비활성화합니다. 가능한 경우 심각한 단점이 있는 RC4 또는 HMAC-MD5를 기반으로 하는 암호 제품군도 비활성화해야 합니다. 즉, 의도적으로 약해졌던 수출 암호 모음에도 동일하게 적용됩니다. 따라서 쉽게 중단할 수 있습니다.
즉시 안전하지 않지만 128비트 미만의 보안을 제공하는 암호화 제품군은 짧은 유효 기간 동안 고려해서는 안 됩니다. 128비트의 보안을 사용하는 알고리즘은 적어도 몇 년 동안 중단되지 않을 수 있으므로 강력하게 권장합니다. 3DES 암호화는 168비트 사용을 알리지만 실제로 112비트의 보안을 제공합니다.
항상 서버 키가 손상된 경우에도 암호화된 데이터의 기밀성을 보장하는 PFS(forward secrecy)를 지원하는 암호화 제품군을 선호합니다. 이 규칙은 빠른 RSA 키 교환을 제한하지만 ECDHE 및 DHE를 사용할 수 있습니다. 이 둘 중 ECDHE는 더 빠르고 선호되는 선택입니다.
또한 Oracle 공격에 취약하지 않으므로 CBC-GCM 이상의 AEAD 암호를 선호해야 합니다. 또한 대부분의 경우 AES-GCM은 특히 하드웨어에 AES용 암호화 가속기가 있는 경우 CBC 모드에서 AES보다 빠릅니다.
또한 ECDSA 인증서와 함께 ECDSA 키 교환을 사용할 때는 트랜잭션이 순수 RSA 키 교환보다 훨씬 빠릅니다. 레거시 클라이언트를 지원하기 위해 서버에 두 쌍의 인증서와 키(새 클라이언트용)와 RSA 키가 있는 키(기존 클라이언트의 경우)를 설치할 수 있습니다.
4.2.3. 공개 키 길이
RSA 키를 사용하는 경우 항상 SHA-256에서 서명한 3072비트 이상의 키 길이를 선호하므로 true 128비트의 보안에 충분합니다.
시스템의 보안은 체인에서 가장 약한 링크만큼 강력합니다. 예를 들어 강력한 암호만으로는 좋은 보안이 보장되지 않습니다. 키와 인증서는 키에 서명하는 데 CA(인증 기관)에서 사용하는 해시 기능 및 키뿐만 아니라 중요합니다.
추가 리소스
- RHEL 8의 시스템 전체 암호화 정책
-
시스템의
update-crypto-policies(8)도움말 페이지
