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

요청이 애플리케이션에 도착할 때마다 요청의 대상이 되는 테넌트를 결정해야 합니다. 다른 지역에서 호스트될 수도 있는 테넌트별 인프라가 있는 경우 수신 요청을 테넌트와 일치시켜야 합니다. 그런 다음, 아래 그림과 같이 해당 테넌트의 리소스를 호스트하는 물리적 인프라로 요청을 전달해야 합니다.

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

테넌트 식별 방법

수신 요청에 대해 테넌트를 식별할 수 있는 방법은 여러 가지가 있습니다.

도메인 이름

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

그러나 다음 질문을 고려해 보세요.

• 사용자가 서비스에 액세스하는 데 사용할 도메인 이름을 어떻게 알 수 있나요?
• 방문 페이지 또는 로그인 페이지와 같이 모든 테넌트에 사용되는 중앙 진입점이 있나요? 진입점이 있는 경우 액세스해야 하는 테넌트를 어떻게 식별하나요?
• 권한 부여 토큰과 같이 테넌트 액세스를 확인하는 데 사용하는 다른 정보는 무엇인가요? 권한 부여 토큰에 테넌트별 도메인 이름이 포함되나요?

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 키는 각 요청과 함께 제공되며 테넌트를 조회하는 데 사용할 수 있습니다.

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 트래픽에 최적화되어 있습니다.
• 사용자가 직접 호스트하는 상용 및 오픈 소스 기술에는 nginx, Traefik 및 HAProxy가 포함됩니다.

요청 유효성 검사

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

요청 유효성 검사를 구현할 때는 다음 사항을 고려해야 합니다.

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

성능

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

세션 선호도

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

다음 질문을 살펴보세요.

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

테넌트 마이그레이션

테넌트는 종종 테넌트 수명 주기 중에 새 인프라로 이동해야 합니다. 테넌트가 새 배포로 이동하면 액세스하는 HTTP 엔드포인트가 변경될 수 있습니다. 이 경우 테넌트 매핑 프로세스를 업데이트해야 합니다. 다음을 고려해야 할 수 있습니다.

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

참가자

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

보안 주체 작성자:

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

기타 기여자:

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

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

다음 단계

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