다음을 통해 공유

Azure Front Door를 사용하는 엔드투엔드 TLS

  • 아티클

Important

TLS 1.0 및 1.1에 대한 지원은 2025년 3월 1일에 중단됩니다.

이전에 SSL(Secure Sockets Layer)로 알려진 TLS(전송 계층 보안)는 웹 서버와 클라이언트(예: 웹 브라우저) 간에 암호화된 링크를 설정하기 위한 표준 보안 기술입니다. 이 링크를 통해 서버와 클라이언트 간에 전달되는 모든 데이터는 프라이빗 및 암호화된 상태로 유지됩니다.

보안 또는 규정 준수 요구 사항을 충족하기 위해 Azure Front Door는 엔드투엔드 TLS 암호화를 지원합니다. Front Door TLS/SSL 오프로드는 TLS 연결을 종료하고, Azure Front Door에서 트래픽의 암호를 해독한 다음, 트래픽을 다시 암호화한 후에 원본에 전달합니다. 원본에 대한 연결이 원본의 공용 IP 주소를 사용하는 경우 보안을 위해 Azure Front Door에서 HTTPS를 전달 프로토콜로 구성하는 것이 좋습니다. HTTPS를 전달 프로토콜로 사용하면 클라이언트에서 원본으로 요청의 전체 처리를 위해 엔드투엔드 TLS 암호화를 적용할 수 있습니다. Private Link 기능을 사용하여 Azure Front Door 프리미엄에 프라이빗 원본을 배포하는 경우 TLS/SSL 오프로드도 지원됩니다.

이 문서에서는 Azure Front Door가 TLS 연결에서 작동하는 방식을 설명합니다. 고유한 사용자 지정 도메인에서 TLS 인증서를 사용하는 방법에 대한 자세한 내용은 사용자 지정 도메인에 대한 HTTPS를 참조하세요. 고유한 사용자 지정 도메인에서 TLS 인증서를 구성하는 방법을 알아보려면 Azure Portal을 사용하여 Azure Front Door에서 사용자 지정 도메인 구성을 참조하세요.

엔드투엔드 TLS 암호화

엔드투엔드 TLS를 사용하면 원본에 전송하는 동안 중요한 데이터를 보호하는 동시에 글로벌 부하 분산 및 캐싱과 같은 Azure Front Door 기능을 활용할 수 있습니다. 일부 기능에는 URL 기반 라우팅, TCP 분할, 클라이언트에 가장 가까운 에지 위치에서 캐싱 및 에지에서 HTTP 요청 사용자 지정도 포함됩니다.

Azure Front Door는 TLS 세션을 에지에서 오프로드하고 클라이언트 요청의 암호를 해독합니다. 다음으로, 구성된 회람 규칙을 적용하여 요청을 원본 그룹의 적절한 원본으로 라우팅합니다. 그러면 Azure Front Door는 원본에 대한 새 TLS 연결을 시작하고, 원본의 인증서를 사용하여 모든 데이터를 다시 암호화한 후에 요청을 원본에 전송합니다. 원본의 모든 응답은 동일한 프로세스를 거쳐 암호화되어 최종 사용자에게 다시 돌아갑니다. 엔드투엔드 TLS를 사용하도록 설정하는 전달 프로토콜로 HTTPS를 사용하도록 Azure Front Door를 구성할 수 있습니다.

지원되는 TLS 버전

Azure Front Door는 현재 TLS 버전 1.0, 1.1, 1.2 및 1.3의 네 가지 버전의 TLS 프로토콜을 지원합니다. 2019년 9월 이후에 만든 모든 Azure Front Door 프로필은 TLS 1.3을 사용하도록 설정된 기본 최소값으로 TLS 1.2를 사용하지만 TLS 1.0 및 TLS 1.1은 이전 버전과의 호환성을 위해 계속 지원됩니다. TLS 1.0 및 1.1에 대한 지원은 2025년 3월 1일에 중단됩니다.

Azure Front Door는 현재 RFC 5246에서 클라이언트/상호 인증을 도입한 TLS 1.2를 지원하지만 Azure Front Door는 아직 mTLS(클라이언트/상호 인증)를 지원하지 않습니다.

Azure Portal 또는 Azure REST API를 사용하여 사용자 지정 도메인 HTTPS 설정에서 Azure Front Door의 최소 TLS 버전을 구성할 수 있습니다. 현재는 1.0과 1.2 중에서 선택할 수 있습니다. 따라서 TLS 1.2를 최소 버전으로 지정하면 Azure Front Door가 클라이언트에서 허용하는 최소 허용 TLS 버전이 제어됩니다. 최소 TLS 버전 1.2의 경우 협상은 TLS 1.3 및 TLS 1.2를 설정하려고 시도하지만 최소 TLS 버전 1.0의 경우 네 가지 버전이 모두 시도됩니다. Azure Front Door에서 원본에 대한 TLS 트래픽을 시작하면 원본에서 안정적이고 일관되게 허용할 수 있는 최상의 TLS 버전을 협상하려고 시도합니다. 원본 연결에 지원되는 TLS 버전은 TLS 1.0, TLS 1.1, TLS 1.2 및 TLS 1.3입니다. TLS 1.0 및 1.1에 대한 지원은 2025년 3월 1일에 중단됩니다.

참고 항목

  • TLS 1.3을 사용하도록 설정된 클라이언트는 TLS 1.3을 사용하여 Azure Front Door를 사용하여 성공적으로 요청하려면 Secp384r1, Secp256r1 및 Secp521을 비롯한 Microsoft SDL 규격 EC 곡선 중 하나를 지원해야 합니다.
  • 클라이언트는 요청 중에 이러한 곡선 중 하나를 기본 곡선으로 사용하여 TLS 핸드셰이크 대기 시간이 늘어나지 않도록 하는 것이 좋습니다. 이 경우 여러 왕복으로 인해 지원되는 EC 곡선을 협상할 수 있습니다.

지원되는 인증서

TLS/SSL 인증서를 만드는 경우 Microsoft 신뢰할 수 있는 CA 목록의 일부인 허용된 CA(인증 기관)를 사용하여 전체 인증서 체인을 만들어야 합니다. 허용되지 않는 CA를 사용하는 경우 요청이 거부됩니다.

내부 CA 또는 자체 서명된 인증서의 인증서는 허용되지 않습니다.

OCSP(온라인 인증서 상태 프로토콜) 스테이플링

OCSP 스테이플링은 Azure Front Door에서 기본적으로 지원되며 구성이 필요하지 않습니다.

원본 TLS 연결(Azure Front Door에서 원본으로)

HTTPS 연결의 경우 Azure Front Door는 원본에서 원본 호스트 이름과 일치하는 주체 이름이 있는 유효한 CA(인증 기관)의 인증서를 제공하도록 요구합니다. 예를 들어 원본 호스트 이름이 myapp-centralus.contosonews.net으로 설정되어 있고 TLS 핸드셰이크 중에 원본에서 제공하는 인증서의 주체 이름에 myapp-centralus.contosonews.net 또는 *.contosonews.net이 없으면 Azure Front Door에서 연결을 거부하고 클라이언트에 오류가 발생합니다.

참고 항목

인증서에는 리프 및 중간 인증서가 있는 전체 인증서 체인이 있어야 합니다. 루트 CA는 Microsoft 신뢰할 수 있는 CA 목록의 일부여야 합니다. 전체 체인이 없는 인증서가 표시되면 해당 인증서와 관련된 요청이 예상대로 작동하지 않을 수 있습니다.

테스트와 같은 특정 사용 사례에서는 HTTPS 연결 실패를 해결하기 위한 방법으로 Azure Front Door에 대한 인증서 주체 이름 확인을 사용하지 않도록 설정할 수 있습니다. 원본은 여전히 유효한 신뢰할 수 있는 체인이 있는 인증서를 제공해야 하지만 원본 호스트 이름과 일치할 필요는 없습니다.

Azure Front Door 표준 및 프리미엄에서 인증서 주체 이름 검사 사용하지 않도록 원본을 구성할 수 있습니다.

Azure Front Door(클래식)의 경우 Azure Portal에서 Azure Front Door 설정을 변경하여 인증서 주체 이름 검사 사용하지 않도록 설정할 수 있습니다. Azure Front Door API에서 백 엔드 풀의 설정을 사용하여 검사 구성할 수도 있습니다.

참고 항목

보안 관점에서 인증서 주체 이름 검사를 사용하지 않도록 설정하는 것이 좋습니다.

프런트 엔드 TLS 연결(클라이언트에서 Azure Front Door로)

Azure Front Door 사용자 지정 도메인에서 콘텐츠를 안전하게 전달하기 위해 HTTPS 프로토콜을 사용하도록 설정하려면 Azure Front Door에서 관리하는 인증서를 사용하거나 사용자 고유의 인증서를 사용하도록 선택할 수 있습니다.

자세한 내용은 사용자 지정 도메인에 대한 HTTPS를 참조하세요.

Azure Front Door의 관리형 인증서는 DigiCert를 통해 표준 TLS/SSL 인증서를 제공하며 Azure Front Door의 Key Vault에 저장됩니다.

사용자 고유의 인증서를 사용하도록 선택하는 경우 표준 TLS, 확장된 유효성 검사 인증서 또는 와일드카드 인증서일 수 있는 지원되는 CA의 인증서를 온보딩할 수 있습니다. 자체 서명된 인증서는 지원되지 않습니다. 사용자 지정 도메인에 HTTPS를 사용하는 방법을 알아보세요.

인증서 자동 회전

Azure Front Door 관리형 인증서 옵션의 경우 인증서는 Azure Front Door에서 90일 만료 시간 이내에 관리되고 자동으로 회전됩니다. Azure Front Door 표준/프리미엄 관리형 인증서 옵션의 경우 인증서는 Azure Front Door에서 45일 만료 시간 이내에 관리되고 자동으로 회전됩니다. Azure Front Door 관리형 인증서를 사용하고 인증서 만료 날짜가 60일 미만이거나 표준/프리미엄 SKU의 경우 30일 미만인 경우 지원 티켓을 제출합니다.

고유한 사용자 지정 TLS/SSL 인증서의 경우:

  1. 키 자격 증명 모음에서 최신 버전의 인증서를 사용할 수 있는 경우 인증서가 최신 버전으로 자동으로 회전되도록 비밀 버전을 '최신'으로 설정합니다. 사용자 지정 인증서의 경우 인증서 만료 시간에 관계없이 인증서는 3~4일 이내에 최신 버전의 인증서로 자동으로 회전됩니다.

  2. 특정 버전을 선택하면 자동 회전이 지원되지 않습니다. 인증서를 회전하려면 새 버전을 수동으로 다시 선택해야 합니다. 새 버전의 인증서/비밀을 배포하는 데 최대 24시간이 걸립니다.

    참고 항목

    Azure Front Door(표준 및 프리미엄) 관리형 인증서는 도메인 CNAME 레코드가 Front Door 엔드포인트를 직접 가리키거나 Traffic Manager 엔드포인트를 간접적으로 가리키는 경우 자동으로 회전됩니다. 그렇지 않으면 도메인 소유권의 유효성을 다시 검사하여 인증서를 순환해야 합니다.

    Front Door의 서비스 주체가 키 자격 증명 모음에 액세스할 수 있는지 확인해야 합니다. Key Vault에 대한 액세스 권한을 부여하는 방법을 참조하세요. 인증서에 대한 주체 이름 또는 SAN(주체 대체 이름)이 변경되지 않는 한, Azure Front Door의 업데이트된 인증서 출시 작업으로 인해 프로덕션 가동 중지 시간이 발생하지 않습니다.

지원되는 암호화 제품군

TLS 1.2/1.3의 경우 다음 암호 그룹이 지원됩니다.

  • TLS_AES_256_GCM_SHA384(TLS 1.3에만 해당)
  • TLS_AES_128_GCM_SHA256(TLS 1.3에만 해당)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

참고 항목

Windows 10 이상 버전의 경우 보안을 강화하기 위해 두 ECDHE_GCM 암호 그룹 중 하나 또는 둘 다를 사용하도록 설정하는 것이 좋습니다. Windows 8.1, 8 및 7은 이러한 ECDHE_GCM 암호 그룹과 호환되지 않습니다. ECDHE_CBC 및 DHE 암호 그룹은 이러한 운영 체제와의 호환성을 위해 제공되었습니다.

TLS 1.0 및 1.1이 설정된 사용자 지정 도메인을 사용하는 경우 다음과 같은 암호 그룹이 지원됩니다.

  • TLS_AES_256_GCM_SHA384(TLS 1.3에만 해당)
  • TLS_AES_128_GCM_SHA256(TLS 1.3에만 해당)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Azure Front Door에서는 프로필에 대한 특정 암호 그룹을 사용하지 않도록 설정하거나 구성하는 것을 지원하지 않습니다.

다음 단계