다중 테넌트 솔루션에서 도메인 이름 사용 시 고려 사항

많은 다중 테넌트 웹 애플리케이션에서 도메인 이름을 사용하여 테넌트를 식별하고 요청을 올바른 인프라로 라우팅할 수 있도록 하며 고객에게 브랜드 경험을 제공할 수 있습니다. 두 가지 일반적인 방법은 하위 도메인을 사용하거나 사용자 지정 도메인 이름을 사용하는 것입니다. 이 페이지에서는 기술 의사 결정자를 위해 고려할 수 있는 접근 방식과 이와 관련된 장단점에 대한 안내를 제공합니다.

하위 영역

각 테넌트는 다음과 같은 tenant.provider.com형식을 사용하여 공통 공유 도메인 이름 아래에 고유한 하위 도메인을 가져올 수 있습니다.

Contoso에서 빌드한 다중 테넌트 솔루션 예제를 살펴보겠습니다. 고객이 청구서 생성 관리에 도움이 되는 Contoso 제품을 구매합니다. Contoso의 모든 테넌트에는 contoso.com 도메인 이름 아래의 자체 하위 도메인이 할당될 수 있습니다. 또는 Contoso에서 지역 배포를 사용하는 경우 하위 도메인 및 eu.contoso.com 도메인에 하위 도메인을 할당할 us.contoso.com 수 있습니다. 이 문서에서는 이를 줄기 도메인이라고 부릅니다. 각 고객은 줄기 도메인 아래에서 자신의 하위 도메인을 가집니다. 예를 들어 Tailwind Toys가 할당 tailwind.contoso.com될 수 있으며 지역 배포 모델에서는 Adventure Works가 할당 adventureworks.us.contoso.com될 수 있습니다.

도메인 네임스페이스 관리

자체 도메인 이름 아래에 하위 도메인을 만들 때는 비슷한 이름의 고객이 많을 수 있다는 점에 주의해야 합니다. 단일 스템 도메인을 공유하기 때문에 특정 도메인을 처음 받는 고객은 선호하는 이름을 얻게 됩니다. 그런 다음 전체 도메인 이름은 전역적으로 고유해야 하므로 후속 고객은 대체 하위 도메인 이름을 사용해야 합니다.

와일드카드 DNS

하위 도메인 관리를 단순화하기 위해서는 와일드카드 DNS 항목을 사용하는 것이 좋습니다. tailwind.contoso.com, adventureworks.contoso.com 등에 대해 DNS 항목을 만드는 대신 *.contoso.com에 대해 와일드카드 항목을 만들고 모든 하위 도메인을 단일 IP 주소(A 레코드) 또는 정식 이름(CNAME 레코드)으로 지정할 수 있습니다. 지역 스템 도메인을 사용하는 경우 다음과 같은 *.us.contoso.com *.eu.contoso.com여러 와일드카드 항목이 필요할 수 있습니다.

다중 파트 줄기 도메인이 있는 하위 도메인

많은 다중 테넌트 솔루션이 여러 물리적 배포에 분산되어 있습니다. 이는 데이터 상주 요구 사항을 준수해야 하거나 사용자에게 지리적으로 더 가까운 리소스를 배포하여 더 나은 성능을 제공하려는 경우 일반적인 방법입니다.

단일 지역 내에서도 확장 전략을 지원하기 위해 독립 배포에 테넌트를 분산해야 할 수도 있습니다. 각 테넌트에 하위 도메인을 사용하려면 다중 파트 하위 도메인 구조를 고려할 수 있습니다.

예를 들어 Contoso는 4명의 고객을 위해 다중 테넌트 애플리케이션을 게시합니다. Adventure Works 및 Tailwind Traders는 미국에 있고 데이터는 미국에 있는 Contoso 플랫폼의 공유 인스턴스에 저장되어 있습니다. Fabrikam 및 Worldwide Importers는 유럽에 있고 데이터는 유럽 인스턴스에 저장되어 있습니다.

Contoso가 모든 고객에 대해 단일 줄기 도메인 contoso.com을 사용하기로 선택한 경우 다음과 같은 결과가 발생할 수 있습니다.

이 구성을 지원하는 데 필요한 DNS 항목은 다음과 같을 수 있습니다.

새 고객이 온보딩되면 새 하위 도메인이 필요하고 고객에 따라 하위 도메인 수가 늘어납니다

또는 Contoso가 다음과 같이 배포 또는 지역에 한정된 줄기 도메인을 사용할 수 있습니다.

그런 다음 와일드카드 DNS를 사용하면 이 배포에 대한 DNS 항목이 다음과 같이 표시될 수 있습니다.

Contoso가 모든 고객에 대해 하위 도메인 레코드를 만들 필요가 없습니다. 대신 각 지역의 배포에 대한 단일 와일드카드 DNS 레코드가 있으며, 그 아래에 추가된 모든 새 고객은 자동으로 CNAME 레코드를 상속합니다.

각 접근 방식에는 장점과 단점이 있습니다. 단일 줄기 도메인을 사용할 때는 온보딩하는 각 테넌트에 대해 새 DNS 레코드를 만들어야 해서 더 많은 운영 오버헤드가 발생합니다. 그러나 CNAME 레코드를 변경하여 트래픽을 다른 배포로 보낼 수 있으므로 배포 간에 테넌트 이동이 더 유연합니다. 이 변경 내용은 다른 테넌트에 영향을 주지 않습니다. 여러 Stem 도메인을 사용하는 경우 관리 오버헤드가 줄어듭니다. 또한 각 Stem 도메인이 자체 네임스페이스를 효과적으로 나타내므로 여러 지역 스템 도메인에서 고객 이름을 다시 사용할 수 있습니다.

사용자 지정 도메인 이름

고객이 자신의 도메인 이름을 가져오도록 허용할 수 있습니다. 일부 고객은 이것을 브랜딩의 중요 요소로 고려합니다. 특히 고객이 자체 TLS 인증서를 제공해야 하는 경우 고객의 보안 요구 사항을 충족하기 위해 사용자 지정 도메인 이름이 필요할 수도 있습니다. 고객이 자체 도메인 이름을 가져오도록 하는 것이 사소한 일로 보일 수 있지만 이 접근 방식에는 몇 가지 숨겨진 복잡성이 존재하므로 신중하게 고려해야 합니다.

이름 확인

궁극적으로 각 도메인 이름은 IP 주소로 확인되어야 합니다. 앞에서 본 것처럼 이름 확인이 수행되는 방법은 솔루션의 단일 인스턴스 또는 여러 인스턴스를 배포하는지에 따라 달라질 수 있습니다.

이 문서의 예시로 돌아가 보겠습니다. Contoso의 고객 중 하나인 Fabrikam은 Contoso의 서비스에 액세스하기 위해 사용자 지정 도메인 이름으로 사용하도록 invoices.fabrikam.com 요청했습니다. Contoso에는 다중 테넌트 플랫폼의 여러 배포가 있으므로 라우팅 요구 사항을 달성하기 위해 하위 도메인 및 CNAME 레코드를 사용하기로 결정합니다. Contoso와 Fabrikam은 다음과 같이 DNS 레코드를 구성합니다.

이름 확인 관점에서 이 레코드 체인은 Contoso 유럽 배포의 IP 주소에 대한 invoices.fabrikam.com 요청을 정확하게 해결합니다.

호스트 헤더 확인

이름 확인은 문제의 절반에 불과합니다. Contoso의 유럽 배포 내의 모든 웹 구성 요소는 요청 헤더에서 Fabrikam의 도메인 이름으로 Host 도착하는 요청을 처리하는 방법을 알고 있어야 합니다. Contoso에서 사용하는 특정 웹 기술에 따라 각 테넌트의 도메인 이름에 대한 추가 구성이 필요할 수 있으므로 테넌트의 온보딩에 추가 작업 오버헤드가 추가됩니다.

또한 들어오는 요청의 Host 헤더에 관계없이 웹 서버에 헤더 값이 일관되게 표시되도록 호스트 헤더를 다시 작성할 수도 있습니다. 예를 들어 Azure Front Door를 사용하면 요청에 관계없이 애플리케이션 서버에 단일 Host 헤더가 수신되도록 Host 헤더를 다시 작성할 수 있습니다. Azure Front Door는 헤더의 원래 호스트 헤더를 X-Forwarded-Host 전파하므로 애플리케이션에서 해당 헤더를 검사한 다음 테넌트 조회를 수행할 수 있습니다. 그러나 헤더를 다시 작성하면 Host 다른 문제가 발생할 수 있습니다. 자세한 내용은 호스트 이름 유지를 참조하세요.

도메인 유효성 검사

온보딩 전 사용자 지정 도메인의 소유권에 대해 유효성 검사를 수행하는 것이 중요합니다. 그렇지 않으면 고객이 우연히 또는 악의적으로 도메인 이름을 파킹할 위험이 있습니다.

invoices.adventureworks.com을 사용자 지정 도메인 이름으로 사용하도록 요청한 Adventure Works에 대한 Contoso의 온보딩 프로세스를 살펴보겠습니다. 사용자 지정 도메인 이름을 온보딩하려고 시도할 때 누군가 오타를 내서 s가 빠졌습니다. 그래서 도메인 이름이 invoices.adventurework.com으로 설정되었습니다. Adventure Works의 트래픽이 올바르게 흐르지 않을 뿐만 아니라 Adventure Work라는 다른 회사가 Contoso의 플랫폼에 사용자 지정 도메인을 추가하려고 할 때 도메인 이름이 이미 사용 중이라는 것을 들었습니다.

특히 셀프 서비스 또는 자동화된 프로세스 내에서 사용자 지정 도메인을 사용할 때는 일반적으로 도메인 확인 단계가 필요합니다. 이렇게 하려면 도메인을 추가하기 전 CNAME 레코드를 설정해야 할 수 있습니다. 또는 Contoso가 임의 문자열을 생성하고 Adventure Works에 해당 문자열 값으로 DNS TXT 레코드를 추가하도록 요청할 수 있습니다. 이렇게 하면 확인이 완료될 때까지 도메인 이름이 추가되지 않습니다.

매달린 DNS 및 하위 도메인 탈취 공격

사용자 지정 도메인 이름을 사용할 때는 잠재적으로 매달린 DNS 또는 하위 도메인 탈취라는 공격에 취약합니다. 이 공격은 고객이 자신의 사용자 지정 도메인 이름을 서비스에서 분리하지만 DNS 서버에서 레코드를 삭제하지 않을 때 발생합니다. 그런 다음, 이 DNS 항목은 존재하지 않는 리소스를 가리키고 탈취에 취약해집니다.

Fabrikam과 Contoso의 관계가 어떻게 바뀔지 살펴보겠습니다.

1. Fabrikam이 Contoso와의 협력을 중단하기로 결정하여 비즈니스 관계를 종료했습니다.
2. Contoso는 Fabrikam 테넌트를 오프보딩하고 fabrikam.contoso.com이 더 이상 작동하지 않도록 요청했습니다. 하지만 Fabrikam에서 invoices.fabrikam.com에 대해 CNAME 레코드를 삭제하는 것을 잊었습니다.
3. 이 때 악의적인 행위자가 새로운 Contoso 계정을 만들고 이름을 fabrikam으로 지정합니다.
4. 이 공격자가 invoices.fabrikam.com이라는 사용자 지정 도메인 이름을 자신의 새 테넌트에 온보딩합니다. Contoso에서 CNAME 기반 도메인 유효성 검사를 수행하므로 Fabrikam의 DNS 서버를 확인합니다. DNS 서버가 fabrikam.contoso.com을 가리키는 invoices.fabrikam.com에 대한 CNAME 레코드를 반환하는 것이 확인됩니다. Contoso에서는 사용자 지정 도메인 유효성 검사가 성공한 것으로 고려됩니다.
5. Fabrikam 직원이 사이트에 액세스하려고 시도하면 요청이 작동하는 것으로 보입니다. 공격자가 자신의 Contoso 테넌트를 Fabrikam의 브랜딩으로 설정한 경우 직원은 이 사이트에 액세스하고 중요한 데이터를 제공하게 될 수 있으며, 공격자가 데이터에 액세스할 수 있습니다.

현수 DNS 공격으로부터 보호하기 위한 일반적인 전략은 다음과 같습니다.

• 테넌트의 계정에서 도메인 이름을 제거하기 전에 CNAME 레코드를 삭제해야 합니다.
• 테넌트 식별자의 재사용을 금지하며, 또한 테넌트가 도메인 이름과 일치하는 이름과 임의로 생성된 값을 사용하여 TXT 레코드를 만들어야 합니다. 이 레코드는 각 온보딩 시도에 대해 변경됩니다.

TLS/SSL 인증서

TLS(전송 계층 보안)는 최신 애플리케이션을 사용할 때 필수적인 구성 요소입니다. 이 인증서는 웹 애플리케이션에 대한 신뢰와 보안을 제공합니다. TLS 인증서의 소유권 및 관리는 다중 테넌트 애플리케이션에 대해 신중하게 고려해야 하는 사항입니다.

일반적으로 도메인 이름의 소유자는 인증서 발급 및 갱신을 담당합니다. 예를 들어 Contoso는 us.contoso.com에 대한 TLS 인증서는 물론 *.contoso.com에 대한 와일드카드 인증서를 발급하고 갱신해야 합니다. 마찬가지로 Fabrikam은 invoices.fabrikam.com을 포함하여 fabrikam.com 도메인에 대한 모든 레코드를 관리해야 합니다.

도메인 소유자가 CAA(인증 기관 권한 부여) DNS 레코드 형식을 사용할 수 있습니다. CAA 레코드는 특정 기관만 도메인에 대한 인증서를 만들 수 있도록 합니다.

고객이 자신의 도메인을 가져오도록 허용하려면 고객 대신 인증서를 발급할지 아니면 고객이 자체 인증서를 가져오도록 해야 할지 고려해야 합니다. 각 옵션에는 다음과 같은 이점과 단점이 있습니다.

• 고객 에 대해 인증서를 발급하는 경우 인증서 갱신을 처리할 수 있으므로 고객은 인증서를 업데이트된 상태로 유지할 필요가 없습니다. 하지만 고객이 자신의 도메인 이름에 CAA 레코드를 사용할 경우에는 고객 대신 인증서를 발급하기 위해 고객에게서 권한을 부여 받아야 할 수 있습니다.
• 고객이 자체 인증서 를 발급하고 제공할 것으로 예상하는 경우 프라이빗 키를 안전하게 수신 및 관리할 책임이 있으며, 서비스 중단을 방지하기 위해 만료되기 전에 인증서를 갱신하도록 고객에게 알려야 할 수 있습니다.

일부 Azure 서비스는 사용자 지정 도메인에 대한 자동 인증서 관리를 지원합니다. 예를 들어 Azure Front Door 및 App Service는 사용자 지정 도메인에 대한 인증서를 제공하며 갱신 프로세스를 자동으로 처리합니다. 따라서 운영 팀의 인증서 관리 부담을 없애 줍니다. 하지만 여전히 CAA 레코드가 유효하고 올바르게 구성되었는지와 같은 소유권 및 권한 관련 문제를 고려해야 합니다. 또한 플랫폼에서 관리되는 인증서를 허용하도록 고객 도메인이 구성되었는지 확인해야 합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• John Downs | 주요 소프트웨어 엔지니어

기타 기여자:

• Daniel Scott-Raynsford | 파트너 기술 전략가
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인하세요.

다음 단계

아키텍처 고려 사항 개요로 돌아갑니다. 또는 Microsoft Azure Well-Architected Framework를 검토합니다.