다중 테넌트 솔루션의 테넌트에 요청 매핑

요청이 애플리케이션에 도착할 때마다 요청을 만드는 테넌트 컨텍스트인 테넌트 컨텍스트를 결정해야 합니다. 다른 지역에서 호스트될 수 있는 테넌트별 인프라가 있는 경우 들어오는 요청을 테넌트에 일치시켜야 합니다. 그런 다음, 다음 다이어그램과 같이 해당 테넌트의 리소스를 호스트하는 물리적 인프라에 요청을 전달해야 합니다.

많은 다중 테넌트 애플리케이션에도 사용자 기반 권한이 있습니다. 테넌트 매핑은 별도의 작업입니다. 요청을 수행하는 사용자와 작업 중인 테넌트 모두를 알아야 합니다.

이 문서에서는 요청을 적절한 테넌트에 매핑하기 위해 고려할 수 있는 접근 방식과 접근 방식과 관련된 장단분에 대한 기술 의사 결정자를 위한 지침을 제공합니다.

테넌트 식별 방법

들어오는 요청에 대한 테넌트를 식별하는 방법에는 여러 가지가 있습니다. 각 방법을 사용하려면 들어오는 요청의 일부 측면을 검사해야 합니다.

도메인 이름

테넌트별 도메인 또는 하위 도메인 이름을 사용하는 경우 각 요청에 대한 원래 호스트 이름을 포함하는 헤더, Host 헤더 또는 다른 HTTP 헤더를 사용하여 X-Forwarded-Host 요청을 테넌트에 쉽게 매핑할 수 있습니다.

그러나 다음 질문을 고려합니다.

• 사용자는 서비스에 액세스하는 데 사용할 도메인 이름을 어떻게 알 수 있나요?
• 모든 테넌트에서 사용하는 방문 페이지 또는 로그인 페이지와 같은 중앙 진입점이 있나요? 이렇게 하면 사용자가 작업 중인 테넌트는 어떻게 선택합니까?
• 권한 부여 토큰과 같은 테넌트의 리소스에 대한 액세스를 확인하는 데 사용하는 다른 정보는 무엇인가요? 권한 부여 토큰에 테넌트별 도메인 이름이 포함되나요?

HTTP 요청 속성

테넌트별 도메인 이름을 사용하지 않는 경우에도 HTTP 요청의 측면을 사용하여 특정 요청이 적용되는 테넌트를 식별할 수 있습니다. 예를 들어 테넌트 이름을 로 tailwindtraders식별하는 HTTP 요청을 고려합니다. 다음 방법 중 하나를 사용하여 통신할 수 있습니다.

• URL 경로 구조(예: https://app.contoso.com/tailwindtraders/.
• URL의 쿼리 문자열(예: https://contoso.com/app?tenant=tailwindtraders.)
• 사용자 지정 HTTP 요청 헤더(예: Tenant-Id: tailwindtraders.

이 방법을 사용하는 경우 다음 질문을 고려해야 합니다.

• 사용자가 서비스에 액세스하는 방법을 알 수 있나요? 예를 들어 쿼리 문자열을 사용하여 테넌트를 식별하는 경우 중앙 방문 페이지에서 쿼리 문자열을 추가하여 사용자를 올바른 테넌트 페이지로 이동해야 합니까?
• 모든 테넌트에서 사용하는 방문 페이지 또는 로그인 페이지와 같은 중앙 진입점이 있나요? 이렇게 하면 사용자가 액세스해야 하는 테넌트는 어떻게 선택합니까?
• 애플리케이션에서 API를 제공하나요? 예를 들어 웹 애플리케이션이 SPA(단일 페이지 애플리케이션) 또는 API 백 엔드가 있는 모바일 애플리케이션인가요? 이 경우 API 게이트웨이 또는 역방향 프록시 를 사용하여 테넌트 매핑을 수행할 수 있습니다.

토큰 클레임

대부분의 애플리케이션은 OAuth 2.0 또는 SAML과 같은 클레임 기반 인증 및 권한 부여 프로토콜을 사용합니다. 이러한 프로토콜은 클라이언트에 권한 부여 토큰을 제공합니다. 토큰에는 클라이언트 애플리케이션 또는 사용자에 대한 정보 조각인 클레임 집합이 포함되어 있습니다. 클레임은 사용자의 이메일 주소와 같은 정보를 전달하는 데 사용할 수 있습니다. 그러면 시스템에서 사용자의 이메일 주소를 포함하고, 사용자-테넌트 매핑을 조회한 다음, 요청을 적절한 배포로 전달할 수 있습니다. 또는 ID 시스템에 테넌트 매핑을 포함하고 토큰에 테넌트 ID 클레임을 추가할 수도 있습니다.

클레임을 사용하여 요청을 테넌트에 매핑하는 경우 다음 질문을 고려해야 합니다.

• 클레임을 사용하여 테넌트를 식별하시겠습니까? 어떤 클레임을 사용합니까?
• 사용자가 여러 테넌트 구성원이 될 수 있나요? 가능한 경우 사용자는 특정 요청에 대해 작업하려는 테넌트를 어떻게 선택합니까?
• 모든 테넌트에 대한 중앙 인증 및 권한 부여 시스템이 있나요? 그렇지 않은 경우 모든 토큰 기관이 일관된 토큰 및 클레임을 발급하도록 하려면 어떻게 해야 할까요?

API 키

많은 애플리케이션에서 API를 노출합니다. 조직 내에서 내부적으로 사용하거나 파트너 또는 고객의 외부 사용을 위한 것일 수 있습니다. API에 대한 일반적인 인증 방법은 API 키를 사용하는 것입니다. API 키는 각 요청과 함께 제공됩니다. 키가 발급된 테넌트 ID를 기록하는 경우 키를 사용할 때 테넌트 ID를 조회할 수 있습니다.

API 키는 여러 가지 방법으로 생성할 수 있습니다. 다음은 두 가지 일반적인 접근 방식입니다.

• 암호화 임의 값을 생성하고 테넌트 ID와 함께 조회 테이블에 저장합니다. 요청이 수신되면 시스템에서 조회 테이블에서 API 키를 찾은 다음 테넌트 ID와 일치합니다.
• 테넌트 ID가 포함된 의미 있는 문자열을 만듭니다. HMAC와 같은 접근 방식을 사용하여 키에 디지털 서명합니다. 각 요청을 처리할 때 서명을 확인한 다음 테넌트 ID를 추출합니다.

다음 질문을 살펴보세요.

• API 키를 생성하고 발급하려면 어떻게 해야 합니까?
• API 클라이언트는 API 키를 안전하게 받고 저장하려면 어떻게 할까요?
• 일정 기간 후에 API 키가 만료되어야 합니까? 가동 중지 시간을 유발하지 않고 클라이언트의 API 키를 어떻게 회전할 수 있나요?
• 고객이 생성한 API 키가 API에 적절한 수준의 보안을 제공합니까?

클라이언트 인증서

mTLS(상호 TLS)라고도 하는 클라이언트 인증서 인증은 일반적으로 서비스 간 통신 및 인증되지 않은 사용자가 사용하는 무인 디바이스 또는 키오스크에 사용됩니다. 클라이언트 인증서는 클라이언트를 인증하는 안전한 방법을 제공합니다. 토큰 및 클레임과 마찬가지로 클라이언트 인증서는 테넌트 확인에 사용할 수 있는 특성을 제공합니다. 예를 들어 인증서의 주체 에는 테넌트 조회에 사용할 수 있는 사용자의 이메일 주소가 포함될 수 있습니다.

테넌트 매핑에 클라이언트 인증서를 사용하려는 경우 다음 요소를 고려합니다.

• 서비스에서 신뢰할 수 있는 클라이언트 인증서를 안전하게 발급하고 갱신하려면 어떻게 해야 할까요? 클라이언트 인증서는 인증서를 관리하고 발급하기 위해 특별한 인프라가 필요하기 때문에 작업하기 복잡할 수 있습니다. 부적절하게 처리되는 경우 이러한 복잡성은 보안을 늘리는 대신 줄일 수 있습니다.
• 클라이언트 인증서는 초기 로그인 요청에만 사용되거나 서비스에 대한 모든 요청에 연결되나요?
• 많은 수의 클라이언트가 있는 경우 인증서 발급 및 관리 프로세스를 관리할 수 없게 되나요?
• 클라이언트 인증서와 테넌트 간의 매핑을 구현하려면 어떻게 해야 할까요?

역방향 프록시

애플리케이션 프록시라고도 하는 역방향 프록시를 사용하여 HTTP 요청을 라우팅할 수 있습니다. 역방향 프록시는 수신 엔드포인트의 요청을 수락하고 요청을 여러 백 엔드 엔드포인트 중 하나로 전달할 수 있습니다. 역방향 프록시는 일부 요청 정보 간의 매핑을 수행하고 애플리케이션 인프라에서 작업을 오프로드할 수 있으므로 다중 테넌트 애플리케이션에 유용합니다.

많은 역방향 프록시는 요청의 속성을 사용하여 테넌트 라우팅에 대한 결정을 내릴 수 있습니다. 대상 도메인 이름, URL 경로, 쿼리 문자열, HTTP 헤더 및 토큰 또는 요청 본문의 일부 내의 클레임도 검사할 수 있습니다.

Azure에서 사용되는 일반적인 역방향 프록시는 다음과 같습니다.

• Azure Front Door 는 전역 부하 분산 장치 및 웹 애플리케이션 방화벽입니다. Microsoft 글로벌 에지 네트워크를 사용하여 빠르고 안전하며 확장성이 뛰어난 웹 애플리케이션을 만듭니다. 규칙 집합을 사용하여 테넌트 식별자를 추출하고 요청의 다른 부분에 넣을 수 있습니다.
• Azure Application Gateway 는 백 엔드 서비스와 동일한 물리적 지역에 배포하는 관리되는 웹 트래픽 부하 분산 장치입니다.
• Azure API Management 는 API 트래픽에 최적화되어 있습니다. Azure API Management는 요청에서 테넌트 정보를 추출하기 위한 많은 유연성을 제공하는 포괄적인 정책 엔진 을 제공합니다.
• 직접 호스팅하는 상용 및 오픈 소스 기술에는 nginx, Traefik 및 HAProxy가 포함됩니다.

요청 유효성 검사

애플리케이션이 수신하는 모든 요청이 테넌트에 대해 권한이 부여되는지 확인하는 것이 중요합니다. 예를 들어 애플리케이션이 사용자 지정 도메인 이름을 사용하여 요청을 테넌트에 매핑하는 경우 애플리케이션에서 받은 각 요청이 해당 테넌트에 대해 권한이 부여되었는지 확인해야 합니다. 요청에 도메인 이름 또는 다른 테넌트 식별자가 포함되어 있더라도 액세스 권한을 자동으로 부여해야 하는 것은 아닙니다. OAuth 2.0을 사용하는 경우 대상 그룹 및 범위 클레임을 검사하여 유효성 검사를 수행합니다.

요청 유효성 검사를 구현할 때 다음 요소를 고려합니다.

• 애플리케이션에 대한 모든 요청에 권한을 부여하려면 어떻게 해야 합니까? 물리적 인프라에 매핑하는 데 사용하는 접근 방식에 관계없이 요청에 권한을 부여해야 합니다.
• 모든 유효성 검사 논리를 직접 구현하는 대신 신뢰할 수 있고 널리 사용되고 잘 유지 관리되는 인증 및 권한 부여 프레임워크 및 미들웨어를 사용합니다. 예를 들어 토큰 서명 유효성 검사 논리 또는 클라이언트 인증서 암호화 라이브러리를 빌드하지 마세요. 대신 유효성을 검사하고 테스트한 애플리케이션 플랫폼(또는 알려진 신뢰할 수 있는 패키지)의 기능을 사용합니다.

Performance

테넌트 매핑 논리는 애플리케이션에 대한 모든 요청에서 실행될 수 있습니다. 솔루션이 증가함에 따라 테넌트 매핑 프로세스의 크기를 얼마나 잘 조정할지 고려합니다. 예를 들어 테넌트 매핑의 일부로 데이터베이스 테이블을 쿼리하는 경우 데이터베이스가 많은 양의 부하를 지원하나요? 테넌트 매핑에 토큰 암호 해독이 필요한 경우 시간이 지남에 따라 계산 요구 사항이 너무 높아질까요? 트래픽이 상당히 미미한 경우 전반적인 성능에 영향을 주지 않을 수 있습니다. 하지만 대규모 애플리케이션이 있는 경우 이 매핑과 관련된 오버헤드가 클 수 있습니다.

세션 쿠키

테넌트 매핑 논리의 성능 오버헤드를 줄이는 한 가지 방법은 세션 쿠키를 사용하는 것입니다. 모든 요청에 대한 매핑을 수행하는 대신 각 세션에 대한 첫 번째 요청에 대해서만 정보를 계산하는 것이 좋습니다. 그러면 애플리케이션이 클라이언트에 세션 쿠키를 제공합니다. 클라이언트는 세션 내의 모든 후속 클라이언트 요청을 사용하여 세션 쿠키를 서비스에 다시 전달합니다.

다음 질문을 살펴보세요.

• 세션 쿠키를 사용하여 테넌트에 대한 매핑 요청의 오버헤드를 줄일 수 있나요?
• 각 테넌트에 대한 물리적 배포에 요청을 라우팅하는 데 사용하는 서비스는 무엇인가요? 이러한 서비스는 쿠키 기반 세션을 지원합니까?

테넌트 마이그레이션

테넌트는 종종 테넌트 라이프사이클의 일부로 새로운 인프라로 이동해야 합니다. 테넌트를 새 배포로 이동하면 액세스하는 HTTP 엔드포인트가 변경될 수 있습니다. 이 경우 테넌트 매핑 프로세스를 변경해야 합니다. 다음 요소를 고려해야 할 수도 있습니다.

• 애플리케이션이 매핑 요청에 도메인 이름을 사용하는 경우 마이그레이션 시 DNS 변경이 필요할 수도 있습니다. DNS 변경은 DNS 서비스에 있는 DNS 항목의 TTL(Time-to-Live)에 따라 클라이언트에 전파하는 데 시간이 걸릴 수 있습니다.
• 마이그레이션 프로세스 중에 마이그레이션이 엔드포인트의 주소를 변경하는 경우 테넌트에 대한 요청을 자동으로 새로 고치는 유지 관리 페이지로 일시적으로 리디렉션하는 것이 좋습니다.

Contributors

Microsoft에서 이 문서를 유지 관리합니다. 그것은 원래 다음 기여자에 의해 작성되었습니다.

대표 저자:

• Daniel Scott-Raynsford | 파트너 기술 전략가

기타 기여자:

• John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
• Paolo Salvatori | 수석 고객 엔지니어, FastTrack for Azure
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

다중 테넌트 애플리케이션에서 도메인 이름을 사용할 때 고려 사항에 대해 알아봅니다.