안내 TLS 표준 준수

전송 계층 보안 (TLS) 프로토콜은 인터넷을 통한 네트워크 통신을 보호하는 기본 수단입니다. 이 문서는 보안 서버를 구성하는 데 도움이되는 간단한 가이드입니다. TLS 표준.

개요

XNUMXD덴탈의 전송 계층 보안 (TLS) 프로토콜은 인터넷을 통한 네트워크 통신을 보호하는 기본 수단입니다. 그것 (그리고 그 전임자, SSL (Secure Sockets Layer))는 수십 년 동안 많은 애플리케이션에서 사용되었지만 특히 방문 할 때 브라우저에서 사용되었습니다. HTTPS 웹 사이트. TLS 일반적으로 백그라운드에서 조용히 작동하지만 생각하는 것과는 반대로 TLS 작동하는 블랙 박스가 아닙니다. 오히려 보안 TLS 다양한 암호화 알고리즘의 협력으로 발생합니다. 게다가, TLS는 이전의 SSL과 마찬가지로 보안 산업과 함께 지속적으로 발전하고 있습니다. 새로운 기술 및 비즈니스 요구 사항을 충족하고 최신 보안 위협을 완화해야합니다. 알고리즘은 시간이 지남에 따라 쓸모 없게되거나 관행이 중단 될 수 있으며, 각 변경 사항은 A의 전반적인 보안에 영향을 미칩니다. TLS 인스턴스 (지금 연결을 보호하는 인스턴스).

이러한 변동성은 다양한 표준 조직이 지침 문서를 발행하도록 동기를 부여하여 TLS 보안은 특정 시장, 부문 또는 서비스에서 확립 될 수 있습니다. 불행히도, 표준 자체는 다른 적용 가능한 문서를 준수해야하는 다른 부문을 가진 수많은 표준이 있습니다. 또한 시간이지나면서 보호하도록 설계된 부문의 변화를 수용하면서 발전합니다.

당연히 현대 표준을 설정하기 위해이 표준 바다를 탐색 TLS 인스턴스는 관리자에게 큰 골칫거리가 될 수 있습니다. 이 문서는 예상을 충족하도록 보안 서버를 구성하는 데 도움이되는 간단한 가이드입니다. TLS 2021 년 표준입니다. (추가적인 도움을 위해 우리는 세계에서 가장 인기있는 웹 서버 솔루션의 구성 예를 제공했습니다. 충수.)

표준

지침을 유지 관리하는 여러 엔터티가 있습니다 TLS 미국 보건 복지부 (HHS) 또는 NIST (National Institute of Standards and Technology)와 같은 네트워크 보안 관련. 간결함을 위해이 기사에서는 가장 많이 채택 된 세 가지 문서 만 연구합니다.

1. XNUMXD덴탈의 건강 보험 이식성 및 책임 성법 (히파)
2. NIST SP 800-52r2 지침
3. XNUMXD덴탈의 결제 카드 산업 데이터 보안 표준 (PCI-DSS)

HIPAA 규정 준수

HIPAA는 1996 년 미국 정부에 의해 제정 된 보호받는 건강 정보 (PHI). PHI는 테스트 결과 또는 진단과 같은 디지털 환자 정보를 나타냅니다. HIPAA 안내 문서 2013 년에 발표 된 내용은 다음과 같습니다.

이동중인 데이터에 대한 유효한 암호화 프로세스는 NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) 구현; 800-77, IPsec VPN 가이드; 또는 800-113, SSL VPN 가이드 또는 FIPS (Federal Information Processing Standards) 140-2 인증을받은 기타.

NIST 표준

2005 년, NIST는 SP (Special Publication) 800-52를 발표했습니다. TLS 정부 서버의 경우. SP 800-52는 이후 버전 SP 800-52r1 (2014) 및 SP 80052r2 (2019)로 대체되었습니다. 이 문서는 현재 안정적인 SP 800-52r2의 지침을 따릅니다.

PCI DSS

PCI-DSS는 전자 상거래 웹 사이트에서 지불 및 카드 정보를 처리하는 방법을 설정하는 PCI (Payment Card Industry) 표준 보안위원회 (SSC)가 유지 관리하는 준수 표준입니다. 올바른 구성에 대하여 TLS 인스턴스, PCI-DSS 상태 :

"강력한 암호화 및 보안 프로토콜 (예 : NIST SP 800-52 및 SP 800-57, OWASP 등)에 대한 정보는 업계 표준 및 모범 사례를 참조하십시오."

TLS 표준 :이 모든 것을 하나로 모으기

이제 각 표준이 기능과 처리하는 데이터에 따라 다른 시스템에 영향을 미친다는 점에 유의해야합니다. 예를 들어 병원 전자 메일 서버는 교환 된 메시지에 환자 정보가 포함될 수 있기 때문에 HIPAA 지침에 속할 수있는 반면 병원의 CRM 시스템에는 신용 카드 및 기타 고객 데이터를 포함 할 수 있기 때문에 PCI-DSS에 속할 수 있습니다. 세 가지 표준을 모두 준수하려면 공통 TLS 모든 문서에 존재하는 매개 변수.

다행히 모든 표준이 NIST의 선택 지침을 따르는 것이 분명합니다. TLS 매개 변수. 즉,이 글을 쓰는 시점에서 SP 800-52r2을 준수하면 서버가 HIPAA 및 PCI-DSS도 준수해야합니다. (좋아, 이건 아니야 정확하게 사실이지만 다음 섹션에서 상황이 더 명확해질 것입니다.)

구성 TLS 매개 변수

보안 수준 TLS 제공하는 가장 큰 영향을 프로토콜 버전 (예 : 1.0, 1.1 등) 및 허용 암호 스위트. 암호는 암호화 및 암호 해독을 수행하는 알고리즘입니다. 그러나 암호 스위트 암호, 키 교환 알고리즘 및 해싱 알고리즘을 포함하여 일련의 알고리즘으로 보안 설정에 사용됩니다. TLS 연결. 대부분 TLS 클라이언트와 서버는 여러 대안을 지원하므로 공통 연결을 선택할 때 보안 연결을 설정할 때 협상해야합니다. TLS 버전 및 암호 제품군.

TLS 프로토콜 버전

에 관한 TLS 버전 지원, NIST SP 800-52r2은 다음을 나타냅니다.

정부 전용 애플리케이션을 지원하는 서버 하여야 한다 사용하도록 구성 TLS 1.2 및 영상을 사용하도록 구성 TLS 1.3도 마찬가지입니다. 이 서버 안 사용하도록 구성 TLS 1.1 및 ~하지 않을 것이다 사용 TLS 1.0, SSL 3.0 또는 SSL 2.0.

...

시민 또는 기업용 애플리케이션을 지원하는 서버 (예 : 클라이언트가 정부 IT 시스템의 일부가 아닐 수 있음) 하여야 한다 협상하도록 구성되다 TLS 1.2 및 영상을 협상하도록 구성되다 TLS 1.3. 사용 TLS 버전 1.1 및 1.0은 일반적으로 권장되지 않지만 시민 및 기업과 상호 작용할 수 있도록 필요한 경우 이러한 버전을 구성 할 수 있습니다. 이러한 서버 ~하지 않을 것이다 SSL 2.0 또는 SSL 3.0 사용을 허용합니다.

기관 하여야 한다 SUPPORT TLS 1.3 1 년 2024 월 XNUMX 일까지.이 날짜 이후 서버는 하여야 한다 SUPPORT TLS 1.3 정부 전용 및 시민 또는 기업용 응용 프로그램 모두에 적용됩니다. 일반적으로 다음을 지원하는 서버 TLS 1.3 영상을 사용하도록 구성 TLS 1.2도 마찬가지입니다. 하나, TLS 1.2를 지원하는 서버에서 비활성화 될 수 있습니다. TLS 1.3 다음과 같이 결정된 경우 TLS 1.2는 상호 운용성을 위해 필요하지 않습니다.

DaVinci에는 TLS 1.0은 금지되며 TLS 1.1은 정부 사이트에서 사용되지 않으며 NIST 지침에 따르면 타사 서비스, 정부 제어 서버와의 호환성을 위해 ５월 구현 TLS 필요한 경우 1.0 및 1.1. PCI-DSS 3.2.1 (현재 버전)에서 호환 서버 지원을 포기해야합니다 for TLS 1.0 및“최소 TLS 1.1, 가급적 TLS 1.2.” HIPAA는 기술적으로 모든 버전의 TLS. 따라서 일반적으로 지원되는 최소 TLS 버전은 1.1입니다. 그러나 PCI-DSS와 NIST는 더 안전한 TLS 1.2 (위에서 볼 수 있듯이 NIST는 TLS 1.3 및 2024 년까지 지원을 요구할 계획).

암호 스위트

TLS 1.2 이전

SP 800-52r2는 다음에 대해 허용되는 다양한 암호 제품군을 지정합니다. TLS 1.2 이하. 이 표준은 특정 암호 제품군에 대한 지원을 요구하지 않지만 더 강력한 암호 제품군 선택에 대한 지침을 제공합니다.

1. 정적 키보다 임시 키를 선호합니다 (즉, DH보다 DHE를 선호하고 ECDH보다 ECDHE를 선호). 임시 키는 완벽한 순방향 비밀 성을 제공합니다.
2. CBC 모드보다 GCM 또는 CCM 모드를 선호합니다. 인증 된 암호화 모드를 사용하면 여러 공격을 방지 할 수 있습니다 (자세한 내용은 섹션 3.3.2 [SP 800-52r2] 참조). 이전 버전에서는 사용할 수 없습니다. TLS 1.2.
3. CCM_8보다 CCM을 선호합니다. 후자는 더 낮은 인증 강도를 제공하는 더 짧은 인증 태그를 포함합니다.

또한 이들은 허용 암호 스위트 TLS 서버는 다양한 플랫폼과 클라이언트를 다루지 않으므로 이러한 알고리즘 중 일부만 사용하는 것이 좋습니다. 새로운 프로토콜 취약점이 발견 된 경우 (또는) 더 많은 암호 모음을 허용하면 서버에 대한 공격 영역을 넓힐 수 있습니다.

TLS 1.3

TLS 1.3에는 훨씬 더 짧은 암호 모음 목록이 있습니다.

• TLS_AES_128_GCM_SHA256 (0x13, 0x01)
• TLS_AES_256_GCM_SHA384 (0x13, 0x02)
• TLS_AES_128_CCM_SHA256 (0x13, 0x04)
• TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

결론

이 간단한 안내서가 자세한 내용을 이해하는 데 도움이되기를 바랍니다. TLS구성 할 때 도움을줍니다 TLS 자신의 서버에서. 우리가 논의한 표준 및 권장 사항과 관련하여 다음 섹션에는 가장 널리 사용되는 웹 서버 솔루션에 적용 할 수있는 예제 구성이 포함되어 있습니다. 온라인 규정 준수를 유지하는 방법에 대한 질문이 있으면 언제든지 이메일로 문의하십시오. Support@SSL.com 또는이 화면 하단의 라이브 채팅 버튼을 클릭합니다.

부록 : 예 TLS 구성

세 가지 사양 문서에 명시된 규칙을 수집하면 최신 보안 서버가 구현해야합니다. TLS 1.2 및 / 또는 TLS 1.3, 짧지 만 다양한 선택된 암호 그룹 목록이 있습니다. 빠른 참조로 시장에서 가장 많이 사용되는 웹 서버에 대한 예제 구성이 아래에 나와 있습니다. 이것은 Mozilla에서 생성 된 "중간"(범용) 구성입니다. SSL 구성 생성기:

... SSLProtocol all -SSLv3-TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256 : ECDHE-RSA-AES128-GCM-SHA256 : ECDHE-ECDSA-AES256-GCM-SHA384 : ECDHE-RSA-AES256-GCM-SHA384 : ECDHE-ECDSA-CHACHA20- POLY1305 : ECDHE-RSA-CHACHA20-POLY1305 : DHE-RSA-AES128-GCM-SHA256 : DHE-RSA-AES256-GCM-SHA384 SSLHonorCipherOrder 끄기 SSLSessionTickets 끄기

... ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

... ssl.openssl.ssl-conf-cmd = ( "프로토콜"=> "모두, -SSLv2, -SSLv3,-TLSv1,-TLSv1.1 ") ssl.cipher-list ="ECDHE-ECDSA-AES128-GCM-SHA256 : ECDHE-RSA-AES128-GCM-SHA256 : ECDHE-ECDSA-AES256-GCM-SHA384 : ECDHE-RSA-AES256-GCM- SHA384 : ECDHE-ECDSA-CHACHA20-POLY1305 : ECDHE-RSA-CHACHA20-POLY1305 : DHE-RSA-AES128-GCM-SHA256 : DHE-RSA-AES256-GCM-SHA384 "ssl.honor-cipher-order ="사용 안함 "

...

ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256 :TLS_AES_256_GCM_SHA384 :TLS_CHACHA20_POLY1305_SHA256 ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 아니요tlsv11 아니요tls-tickets

ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256 :TLS_AES_256_GCM_SHA384 :TLS_CHACHA20_POLY1305_SHA256 ssl-default-server-options no-sslv3 no-tlsv10 아니요tlsv11 아니요tls-티켓

... 정책 :-PolicyName : Mozilla-intermediate-v5-0 PolicyType : SSLNegotiationPolicyType 속성 :-이름 : 프로토콜-TLSv1.2 값 : true-이름 : Server-Defined-Cipher-Order 값 : false-이름 : ECDHE-ECDSA-AES128-GCM-SHA256 값 : true-이름 : ECDHE-RSA-AES128-GCM-SHA256 값 : true- 이름 : ECDHE-ECDSA-AES256-GCM-SHA384 값 : true-이름 : ECDHE-RSA-AES256-GCM-SHA384 값 : true-이름 : DHE-RSA-AES128-GCM-SHA256 값 : true-이름 : DHE-RSA -AES256-GCM-SHA384 값 : true