Front Door(클래식) 사용자 지정 도메인에서 HTTPS 구성

  • 아티클

Important

Azure Front Door(클래식)는 2027년 3월 31일에 사용이 중지됩니다. 서비스가 중단되지 않도록 하려면 2027년 3월까지 Azure Front Door(클래식) 프로필을 Azure Front Door 표준 또는 프리미엄 계층으로 마이그레이션하는 것이 중요합니다. 자세한 내용은 Azure Front Door(클래식) 사용 중지를 참조하세요.

이 문서에서는 프런트 엔드 호스트 섹션의 Front Door(클래식)에 연결된 사용자 지정 도메인에 HTTPS 프로토콜을 사용하도록 설정하는 방법을 보여줍니다. 사용자 지정 도메인(예: https://www.contoso.com)에서 HTTPS 프로토콜을 사용하면 인터넷에서 중요한 데이터를 보낼 때 TLS/SSL 암호화를 통해 안전하게 보호됩니다. 웹 브라우저가 HTTPS를 사용하여 웹 사이트에 연결되면 웹 사이트 보안 인증서의 유효성을 검사하고 합법적인 인증 기관에서 발급되었는지 확인합니다. 이 프로세스는 보안을 제공하며 악의적인 공격으로부터 웹 애플리케이션을 보호합니다.

Azure Front Door는 기본적으로 Front Door 기본 호스트 이름에 HTTPS를 지원합니다. 예를 들어 Front Door(예: https://contoso.azurefd.net)를 만들면 https://contoso.azurefd.net에 수행되는 요청에 대해 HTTPS가 자동으로 활성화됩니다. 그러나 'www.contoso.com' 사용자 지정 도메인을 온보딩하면 HTTPS를 이 프런트 엔드 호스트에 추가로 사용하도록 설정해야 합니다.

사용자 지정 HTTPS 기능의 몇 가지 주요 특성은 다음과 같습니다.

  • 추가 비용 없음: 인증서 얻기 또는 갱신에 드는 비용이 없으며 HTTPS 트래픽에 대한 추가 비용도 없습니다.

  • 간단한 사용: Azure Portal에서 한 번 클릭으로 프로비전을 사용할 수 있습니다. REST API 또는 기타 개발자 도구를 사용하여 기능을 활성화할 수도 있습니다.

  • 완전한 인증서 관리 사용 가능: 사용자를 위해 모든 인증서 조달 및 관리가 처리됩니다. 인증서는 만료되기 전에 자동으로 프로비저닝되고 갱신되므로 인증서 만료로 인한 서비스 중단 위험이 제거됩니다.

이 자습서에서는 다음을 하는 방법을 알아볼 수 있습니다.

  • 사용자 지정 도메인에서 HTTPS 프로토콜을 사용하도록 설정
  • AFD 관리 인증서 사용
  • 사용자 고유의 인증서, 즉 사용자 지정 TLS/SSL 인증서 사용
  • 도메인의 유효성 검사
  • 사용자 지정 도메인에서 HTTPS 프로토콜을 사용하지 않도록 설정

참고 항목

Azure Az PowerShell 모듈을 사용하여 Azure와 상호 작용하는 것이 좋습니다. 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Azure로 마이그레이션을 참조하세요.

필수 조건

이 자습서에서 단계를 완료하기 전에 먼저 Front Door를 만들고 하나 이상의 사용자 지정 도메인을 등록해야 합니다. 자세한 내용은 자습서: Front Door에 사용자 지정 도메인 추가를 참조하세요.

TLS/SSL 인증서

Front Door(클래식) 사용자 지정 도메인에서 콘텐츠를 안전하게 제공하기 위해 HTTPS 프로토콜을 활성화하려면 TLS/SSL 인증서를 사용해야 합니다. Azure Front Door에서 관리되는 인증서를 사용하거나 사용자 고유의 인증서를 사용하도록 선택할 수 있습니다.

옵션 1(기본값): Front Door에서 관리되는 인증서 사용

Azure Front Door에서 관리되는 인증서를 사용하면 몇 가지 설정을 변경하여 HTTPS 기능을 설정할 수 있습니다. Azure Front Door는 조달 및 갱신과 같은 인증서 관리 작업을 완전히 처리합니다. 기능을 활성화하면 프로세스는 즉시 시작됩니다. 사용자 지정 도메인이 Front Door의 기본 프런트 엔드 호스트({hostname}.azurefd.net)에 이미 매핑된 경우 추가적인 조치가 필요하지 않습니다. Front Door는 단계를 처리하고 자동으로 요청을 완료합니다. 그러나 사용자 지정 도메인이 다른 곳에 매핑된 경우 이메일을 사용하여 도메인 소유권의 유효성을 검사해야 합니다.

사용자 지정 도메인에서 HTTPS를 활성화하려면 다음 단계를 따르세요.

  1. Azure Portal에서 Front Door 프로필로 이동합니다.

  2. 프런트 엔드 호스트 목록에서 사용자 지정 도메인을 포함하기 위해 HTTPS를 활성화하려는 사용자 지정 도메인을 선택합니다.

  3. 사용자 지정 도메인 HTTPS 섹션 아래에서 사용을 선택하고, 인증서 원본으로 Front Door 관리됨을 선택합니다.

  4. [저장]을 선택합니다.

  5. 계속해서 도메인의 유효성 검사를 진행합니다.

참고 항목

  • Azure Front Door 관리형 인증서의 경우 DigiCert의 64자 제한이 적용됩니다. 해당 제한을 초과하면 유효성 검사가 실패합니다.
  • Front Door 관리 인증서를 통해 HTTPS를 사용하도록 설정하는 것은 apex/root 도메인(예: contoso.com)에 지원되지 않습니다. 이 시나리오에는 사용자 고유의 인증서를 사용할 수 있습니다. 자세한 내용은 옵션 2로 계속 진행하세요.

옵션 2: 사용자 고유의 인증서 사용

사용자 고유의 인증서를 사용하여 HTTPS 기능을 활성화합니다. 이 프로세스는 인증서를 안전하게 저장할 수 있도록 하는 Azure Key Vault와의 통합을 통해 수행됩니다. Azure Front Door는 이 보안 메커니즘을 사용하여 인증서를 가져오며, 몇 가지 추가 단계를 수행해야 합니다. TLS/SSL 인증서를 만들 때 Microsoft 신뢰할 수 있는 CA 목록의 일부인 허용된 CA(인증 기관)를 사용하여 전체 인증서 체인을 만들어야 합니다. 허용되지 않는 CA를 사용하면 요청이 거부됩니다. 전체 체인이 없는 인증서가 표시되는 경우 해당 인증서와 관련된 요청이 예상대로 작동하지 않을 수 있습니다.

Key Vault 및 인증서 준비

  • Front door와 동일한 Azure 구독에 Key Vault 계정이 있어야 합니다. Key Vault 계정이 없는 경우 만듭니다.

    Warning

    Azure Front Door는 현재 Front Door 구성과 동일한 구독의 Key Vault 계정만 지원합니다. Front Door와 다른 구독의 Key Vault를 선택하면 실패하게 됩니다.

  • Key Vault에 사용하도록 설정된 네트워크 액세스 제한이 있는 경우 신뢰할 수 있는 Microsoft 서비스에서 방화벽을 무시할 수 있도록 Key Vault를 구성해야 합니다.

  • 키 자격 증명 모음은 Key Vault 액세스 정책 권한 모델을 사용하도록 구성해야 합니다.

  • 인증서가 이미 있는 경우 Key Vault에 직접 업로드할 수 있습니다. 그렇지 않은 경우 Azure Key Vault가 통합되는 파트너 CA(인증 기관) 중 하나에서 Azure Key Vault를 통해 직접 새 인증서를 만듭니다. 인증서를 비밀 대신 인증서 개체로 업로드합니다.

참고 항목

Front Door는 EC(타원 곡선) 암호화 알고리즘을 사용하는 인증서를 지원하지 않습니다. 인증서에는 리프 및 중간 인증서를 포함하는 전체 인증서 체인이 있어야 하며, 루트 CA가 Microsoft 신뢰할 수 있는 CA 목록에 있어야 합니다.

Azure Front Door 등록

Azure PowerShell 또는 Azure CLI를 사용하여 Microsoft Entra ID에 Azure Front Door의 서비스 주체를 앱으로 등록합니다.

참고 항목

  • 이 작업을 수행하려면 Microsoft Entra ID에서 애플리케이션 관리자 역할 이상의 권한이 필요합니다. 등록은 Microsoft Entra 테넌트당 한 번만 수행하면 됩니다.
  • 애플리케이션 ID는 특히 Azure Front Door(클래식)에 대해 Azure에서 할당합니다.
  • Azure Front Door(클래식)에는 Azure Front Door 표준/프리미엄 계층과 다른 ‘애플리케이션 ID’가 있습니다.
  • 할당된 역할은 다른 범위를 정의하지 않는 한 선택한 구독에만 해당됩니다.
Azure PowerShell

  1. 필요한 경우 로컬 컴퓨터의 PowerShell에 Azure PowerShell을 설치합니다.

  2. PowerShell에서 다음 명령을 실행합니다.

    New-AzADServicePrincipal -ApplicationId "ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037"
Azure CLI

  1. 필요한 경우 로컬 컴퓨터에 Azure CLI를 설치합니다.

  2. CLI에서 다음 명령을 실행합니다.

    az ad sp create --id ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037

키 자격 증명 모음에 Azure Front Door 액세스 권한 부여

Azure Key Vault 계정의 인증서에 액세스하기 위한 Azure Front Door 사용 권한을 부여합니다.

  1. Key Vault 계정에서 액세스 정책을 선택합니다.

  2. 만들기를 선택하여 새 액세스 정책을 만듭니다.

  3. 비밀 사용 권한에서 가져오기를 선택하여 Front Door가 인증서를 검색하도록 허용합니다.

  4. 인증서 사용 권한에서 가져오기를 선택하여 Front Door가 인증서를 검색하도록 허용합니다.

  5. 주체 선택에서 ad0e1c7e-6d38-4ba4-9efd-0bc77ba9f037을 검색하고 Microsoft.Azure.Frontdoor를 선택합니다. 다음을 선택합니다.

  6. 애플리케이션에서 다음을 선택합니다.

  7. 검토 + 만들기에서 만들기를 선택합니다.

참고 항목

Key Vault가 네트워크 액세스 제한으로 보호되는 경우 신뢰할 수 있는 Microsoft 서비스에서 Key Vault에 액세스할 수 있도록 허용해야 합니다.

이제 Azure Front Door에서 이 Key Vault와 여기에 포함된 인증서에 액세스할 수 있습니다.

배포할 Azure Front Door 인증서 선택

  1. 포털에서 Front Door로 돌아갑니다.

  2. 사용자 지정 도메인 목록에서 HTTPS를 사용하도록 설정할 사용자 지정 도메인을 선택합니다.

    사용자 지정 도메인 페이지가 나타납니다.

  3. 인증서 관리 유형에서 내 인증서 사용을 선택합니다.

  4. Azure Front Door를 사용하려면 Key Vault 계정의 구독이 Front Door와 동일해야 합니다. 키 자격 증명 모음, 비밀 및 비밀 버전을 선택합니다.

    Azure Front Door는 다음과 같은 정보를 나열합니다.

    • 구독 ID에 대한 키 자격 증명 모음 계정
    • 선택한 키 자격 증명 모음의 비밀
    • 사용 가능한 비밀 버전

    참고 항목

    Key Vault에서 최신 버전의 인증서를 사용할 수 있을 때 인증서를 최신 버전으로 자동 회전하려면 비밀 버전을 '최신'으로 설정합니다. 특정 버전을 선택한 경우 인증서 회전을 위해 새 버전을 수동으로 다시 선택해야 합니다. 새 버전의 인증서/암호가 배포되는 데 72 - 96시간이 걸립니다.

    사용자 지정 도메인 업데이트 페이지에서 비밀 버전을 선택하는 스크린샷.

    Warning

    이는 Azure Portal 전용 경고입니다. Key Vault에 대한 GET 권한을 갖도록 서비스 주체를 구성해야 합니다. 사용자가 포털 드롭다운에서 인증서를 보려면 사용자 계정에 Key Vault에 대한 LIST 및 GET 권한이 있어야 합니다. 사용자에게 이러한 권한이 없는 경우 포털에 액세스할 수 없는 오류 메시지가 표시됩니다. 액세스할 수 없는 오류 메시지는 인증서 자동 회전 또는 HTTPS 함수에 영향을 주지 않습니다. 인증서 또는 버전을 변경하지 않으려는 경우 이 오류 메시지에 대한 작업이 필요하지 않습니다. 이 페이지의 정보를 변경하려면 Key Vault에 대한 권한 제공을 참조하여 Key Vault의 LIST 및 GET 권한에 계정을 추가합니다.

  5. 사용자 고유의 인증서를 사용하는 경우 도메인 유효성 검사가 필요하지 않습니다. 계속해서 전파 대기를 진행합니다.

도메인의 유효성 검사

CNAME 레코드를 사용하여 사용자 지정 엔드포인트에 매핑되는 사용자 지정 도메인을 이미 사용하고 있거나 사용자 고유의 인증서를 사용하고 있는 경우 사용자 지정 도메인이 Front Door에 매핑됨으로 계속 진행합니다. 그렇지 않고 도메인에 대한 CNAME 레코드 항목이 더 이상 있지 않거나 afdverify 하위 도메인을 포함하는 경우 사용자 지정 도메인이 Front Door에 매핑되지 않음으로 계속 진행합니다.

CNAME 레코드를 통해 사용자 지정 도메인이 CNAME 레코드에 매핑됨

Front Door의 프런트 엔드 호스트에 사용자 지정 도메인을 추가한 경우 도메인 등록 기관의 DNS 테이블에 Front Door의 기본 .azurefd.net 호스트 이름에 매핑할 CNAME 레코드를 만들었습니다. 해당 CNAME 레코드가 여전히 있고 afdverify 하위 도메인을 포함하지 않는 경우 DigiCert 인증 기관에서 이 레코드를 사용하여 사용자 지정 도메인의 소유권을 자동으로 확인합니다.

사용자 고유의 인증서를 사용 중인 경우 도메인 유효성 검사가 필요하지 않습니다.

CNAME 레코드는 다음 형식이어야 합니다. 여기서 Name은 사용자 지정 도메인 이름이고 Value는 Front Door의 기본 .azurefd.net 호스트 이름입니다.

이름 타입 값
<www.contoso.com> CNAME contoso.azurefd.net

CNAME 레코드에 대한 자세한 내용은 CNAME DNS 레코드 만들기를 참조하세요.

CNAME 레코드가 올바른 형식이면 DigiCert는 사용자 지정 도메인 이름을 자동으로 확인하고 도메인 이름에 전용 인증서를 만듭니다. DigitCert는 확인 이메일을 보내지 않으며 요청을 승인할 필요가 없습니다. 인증서는 1년 동안 유효하며 만료되기 전에 자동으로 갱신됩니다. 계속해서 전파 대기를 진행합니다.

일반적으로 자동 유효성 검사에 몇 분 정도 걸립니다. 1시간 내에 도메인의 유효성이 확인되지 않으면 지원 티켓을 엽니다.

참고 항목

DNS 공급자가 포함된 CAA(Certificate Authority Authorization) 레코드가 있으면 DigiCert가 유효한 CA로 포함되어야 합니다. CAA 레코드를 사용하면 도메인 소유자가 자신의 도메인에 대한 인증서를 발급할 권한이 있는 CA를 DNS 공급자로 지정할 수 있습니다. CA에서 CAA 레코드가 있는 도메인에 대한 인증서 주문을 받고 해당 CA가 인증된 발급자로 나열되지 않은 경우 해당 도메인 또는 하위 도메인에 인증서를 발급할 수 없습니다. CAA 레코드 관리에 대한 내용은 CAA 레코드 관리를 참조하세요. CAA 레코드 도구는 CAA 레코드 도우미를 참조하세요.

사용자 지정 도메인이 Front Door에 매핑되지 않음

엔드포인트에 대한 CNAME 레코드 항목이 더 이상 없거나 afdverify 하위 도메인을 포함하는 경우 이 단계의 나머지 지침을 따르세요.

사용자 지정 도메인에서 HTTPS를 활성화한 후에 DigiCert CA에서 도메인의 WHOIS 등록자 정보에 따라 등록자에게 연락하여 도메인 소유권에 대한 유효성을 검사합니다. 기본적으로 WHOIS에 등록된 전자 메일 주소 또는 전화 번호를 통해 연락합니다. 사용자 지정 도메인에서 HTTPS를 활성화하기 전에 도메인 유효성 검사를 완료해야 합니다. 업무일 기준 6일 이내 도메인이 승인되어야 합니다. 6 영업일 이내에 승인되지 않은 요청은 자동으로 취소됩니다. DigiCert 도메인 유효성 검사는 하위 도메인 수준에서 작동합니다. 각 하위 도메인의 소유권을 별도로 증명해야 합니다.

WHOIS 레코드

또한 DigiCert는 확인 이메일을 다른 이메일 주소로 보냅니다. WHOIS 등록자 정보가 프라이빗인 경우 다음 주소 중 하나에서 직접 승인할 수 있는지 확인합니다.

admin@<your-domain-name.com> administrator@<your-domain-name.com> webmaster@<your-domain-name.com> hostmaster@<your-domain-name.com> postmaster@<your-domain-name.com>

잠시 후 다음 예제와 비슷한 승인 요청 전자 메일을 받게 됩니다. 스팸 필터를 사용하는 경우 no-reply@digitalcertvalidation.com을 허용 목록에 추가합니다. 특정 시나리오에서는 DigiCert가 WHOIS 등록자 정보에서 도메인 연락처를 페치하여 이메일을 보내지 못할 수 있습니다. 24시간 이내에 전자 메일을 받지 못하면 Microsoft 지원에 문의하세요.

승인 링크가 선택되면 온라인 승인 양식으로 이동합니다. 양식의 지침을 따르세요. 다음과 같이 두 가지 확인 옵션이 있습니다.

  • 동일한 루트 도메인의 동일한 계정을 통해 이루어진 모든 향후 주문을 승인할 수 있습니다(예: consoto.com). 동일한 루트 도메인에 대해 더 많은 사용자 지정 도메인을 추가하려는 경우 이 방법을 사용하는 것이 좋습니다.

  • 이 요청에 사용된 특정 호스트 이름을 승인할 수 있습니다. 후속 요청에는 추가 승인이 필요합니다.

승인 후에 DigiCert는 사용자 지정 도메인 이름에 대한 인증서 생성을 완료합니다. 인증서는 1년 동안 유효하며 만료되기 전에 자동으로 갱신됩니다.

전파 대기

도메인 이름이 확인된 후 사용자 지정 도메인 HTTPS 기능이 활성 상태가 될 때까지는 최대 6-8시간 소요됩니다. 프로세스가 완료되면 Azure Portal에서 사용자 지정 HTTPS 상태가 사용으로 설정되고 사용자 지정 도메인 대화 상자의 네 가지 작업 단계가 '완료'로 표시됩니다. 사용자 지정 도메인은 이제 HTTPS를 활성화할 준비가 되었습니다.

작업 진행 상태

다음 표에는 HTTPS를 활성화하도록 설정했을 때 나타나는 작업 진행률을 표시합니다. HTTPS를 사용하도록 설정하면 네 가지 작업 단계가 사용자 지정 도메인 대화 상자에 나타납니다. 각 단계가 활성화되면 단계가 진행됨에 따라 더 많은 하위 단계 세부 정보가 표시됩니다. 이러한 하위 단계가 모두 발생하지는 않습니다. 단계가 성공적으로 완료되면 옆에 녹색 확인 표시가 나타납니다.

작업 단계 작업 하위 단계 정보
1. 요청 제출 요청 제출
HTTPS 요청을 제출하는 중입니다.
HTTPS 요청이 제출되었습니다.
2. 도메인 유효성 검사 Front Door의 기본 .azurefd.net 프런트 엔드 호스트에 매핑된 CNAME인 경우 도메인의 유효성이 자동으로 검사됩니다. 그렇지 않으면 도메인의 등록 레코드(WHOIS 등록자)에 나열된 이메일로 확인 요청이 발송됩니다. 최대한 신속하게 도메인을 확인하세요.
도메인 소유권을 확인했습니다.
도메인 소유권 유효성 검사 요청이 만료되었습니다(고객이 6일 이내의 응답하지 않았음). 도메인에서 HTTPS를 사용할 수 없습니다. *
고객에 의해 도메인 소유권 유효성 검사 요청이 거부되었습니다. 도메인에서 HTTPS를 사용할 수 없습니다. *
3. 인증서 프로비저닝 인증 기관이 현재 도메인에서 HTTPS를 활성화하는 데 필요한 인증서를 발급 중입니다.
인증서가 발급되었고 현재 Front Door로 배포되고 있습니다. 이 프로세스를 완료하려면 몇 분에서 한 시간까지 걸릴 수 있습니다.
인증서가 Front Door에 성공적으로 배포되었습니다.
4. 완료 도메인에서 HTTPS를 활성화하도록 설정했습니다.

* 오류가 발생하지 않으면 이 메시지가 표시되지 않습니다.

요청을 제출하기 전에 오류가 발생하는 경우 다음과 같은 오류 메시지가 표시됩니다.

We encountered an unexpected error while processing your HTTPS request. Please try again and contact support if the issue persists.

자주 묻는 질문

  1. 인증서 공급자는 누구이며 어떤 유형의 인증서가 사용되나요?

    Digicert에서 제공한 전용/단일 인증서가 사용자 지정 도메인에 사용됩니다.

  2. IP 기반 또는 SNI TLS/SSL을 사용하나요?

    Azure Front Door는 SNI TLS/SSL을 사용합니다.

  3. DigiCert로부터 도메인 확인 메일을 받지 못한 경우 어떻게 하나요?

    엔드포인트 호스트 이름을 직접 가리키는 사용자 지정 도메인에 대한 CNAME 항목이 있고 afdverify 하위 도메인 이름을 사용하지 않는 경우 도메인 확인 메일을 받지 못합니다. 유효성 검사가 자동으로 수행됩니다. 그렇지 않은 경우 CNAME 항목이 없고 24시간 내에 이메일을 받지 못했으면 Microsoft 지원에 문의하세요.

  4. SAN 인증서를 사용하는 것보다 전용 인증서를 사용하는 것이 더 안전한가요?

    SAN 인증서는 전용 인증서와 동일한 암호화 및 보안 표준을 따릅니다. 발급된 모든 TLS/SSL 인증서는 향상된 서버 보안을 위해 SHA-256을 사용합니다.

  5. 내 DNS 공급자에게 CAA(Certificate Authority Authorization) 레코드가 필요합니까?

    아니요, CAA 레코드는 현재 필요하지 않습니다. 그러나 이 레코드가 있으면 DigiCert가 유효한 CA로 포함되어야 합니다.

리소스 정리

이전 단계에서는 사용자 지정 도메인에 HTTPS 프로토콜을 사용했습니다. HTTPS에서 사용자 지정 도메인을 더 이상 사용하지 않으려면 다음 단계를 수행하여 HTTPS를 사용하지 않도록 설정할 수 있습니다.

HTTPS 기능을 사용하지 않도록 설정

  1. Azure Portal에서 Azure Front Door 구성으로 이동합니다.

  2. 프런트 엔드 호스트 목록에서 HTTPS를 사용하지 않도록 설정하려는 사용자 지정 도메인을 선택합니다.

  3. 사용 안 함을 선택하여 HTTPS를 비활성화한 다음, 저장을 선택합니다.

전파 대기

사용자 지정 도메인 HTTPS 기능을 비활성화한 후 최대 6-8시간까지 걸릴 수 있습니다. 프로세스가 완료되면 Azure Portal에서 사용자 지정 HTTPS 상태가 사용 안 함으로 설정되고 사용자 지정 도메인 대화 상자의 세 가지 작업 단계가 '완료'로 표시됩니다. 사용자 지정 도메인은 더 이상 HTTPS를 사용할 수 없습니다.

작업 진행 상태

다음 표에는 HTTPS를 비활성화하도록 설정했을 때 나타나는 작업 진행률을 표시합니다. HTTPS를 사용하지 않도록 설정하면 세 가지 작업 단계가 사용자 지정 도메인 대화 상자에 나타납니다. 각 단계가 활성화되면 단계 아래에 자세한 정보가 표시됩니다. 단계가 성공적으로 완료되면 옆에 녹색 확인 표시가 나타납니다.

작업 진행 상태 작업 세부 정보
1. 요청 제출 요청 제출
2. 인증서 프로비전 해제 인증서 삭제
3. 완료 인증서 삭제됨

다음 단계

Front Door에 대한 지역 필터링 정책을 설정하는 방법을 알아보려면 다음 자습서를 계속 진행합니다.