다음을 통해 공유

다중 테넌트 아키텍처에서 Azure Active Directory B2C를 사용하기 위한 고려 사항

  • 아티클

Azure AD(Azure Active Directory) B2C는 비즈니스-소비자 ID를 서비스로 제공합니다. 사용자 ID는 일반적으로 다중 테넌트 애플리케이션을 디자인할 때 기본 고려 사항 중 하나입니다. ID 솔루션은 애플리케이션의 게이트키퍼 역할을 하여 테넌트가 정의한 경계 내에 유지되도록 합니다. 이 문서에서는 다중 테넌트 솔루션에서 Azure AD B2C를 사용하기 위한 고려 사항 및 방법을 설명합니다.

Azure AD B2C를 사용하는 가장 일반적인 이유 중 하나는 애플리케이션에 대한 ID 페더레이션을 사용하도록 설정하는 것입니다. ID 페더레이션은 사용자가 기존 계정으로 로그인할 수 있도록 두 ID 공급자 간에 트러스트를 설정하는 프로세스입니다. Azure AD B2C를 사용하는 경우 ID 페더레이션을 구현하여 사용자가 소셜 또는 엔터프라이즈 계정 사용하여 로그인할 수 있도록 할 수 있습니다. 페더레이션을 사용하는 경우 사용자는 애플리케이션과 관련된 별도의 로컬 계정을 만들 필요가 없습니다.

이 항목을 접하는 경우 다음 리소스를 검토하는 것이 좋습니다.

참고 항목

이 문서에서는 애플리케이션 테넌트 및 Azure AD B2C 테넌트라는 두 가지 유사한 이름의 개념에 대해 설명합니다.

애플리케이션 테넌트라는 용어는 테넌트(고객 또는 사용자 그룹)를 참조하는 데 사용됩니다.

또한 Azure AD B2C는 개별 디렉터리를 참조하여 테넌트 개념을 사용하며, 다중 테넌트라는 용어는 여러 Azure AD B2C 테넌트 간의 상호 작용을 참조하는 데 사용됩니다. 용어는 동일하지만 개념은 그렇지 않습니다. 이 문서에서 Azure AD B2C 테넌트를 참조하는 경우 전체 용어 Azure AD B2C 테넌트가 사용됩니다.

다중 테넌트 솔루션의 ID

다중 테넌트 솔루션에서는 여러 ID 서비스를 결합하여 다양한 요구 사항 집합을 달성하는 것이 일반적입니다. 많은 솔루션에는 다음과 같은 두 가지 ID 집합이 있습니다.

  • 최종 사용자 계정에 대한 고객 ID입니다. 테넌트의 사용자가 애플리케이션에 액세스하는 방법을 제어합니다.
  • 자체 팀이 솔루션을 관리하는 방법을 처리하는 내부 ID입니다.

이러한 다양한 ID 유형은 일반적으로 고유 ID 서비스를 사용합니다. Azure AD B2C는 테넌트 사용자가 솔루션에 액세스하는 데 사용하는 CIAM(고객 ID 및 액세스 관리) 서비스입니다. Microsoft Entra ID 는 사용자와 팀이 Azure 리소스를 관리하고 애플리케이션을 제어하는 데 사용하는 IAM(ID 및 액세스 관리) 서비스입니다.

Fabrikam에서 빌드한 다중 테넌트 솔루션 예제를 생각해 보세요. 이 솔루션은 두 서비스의 조합을 사용하여 Fabrikam의 요구 사항을 충족합니다.

  • Fabrikam은 회사의 고객(테넌트)이 애플리케이션에 로그인할 수 있도록 Azure AD B2C를 구현합니다.
  • Fabrikam의 직원은 조직의 Microsoft Entra 디렉터리를 사용하여 관리 및 관리 목적으로 솔루션에 액세스할 수 있습니다. Microsoft Office와 같은 다른 Fabrikam 리소스에 액세스하는 데 사용하는 것과 동일한 ID를 사용합니다.

아래 다이어그램은 이 예제를 보여 줍니다.

두 가지 로그인 방법을 사용하는 두 애플리케이션을 보여 주는 다이어그램

격리 모델

Azure AD B2C를 사용하는 경우 여러 애플리케이션 테넌트 간에 사용자 계정을 격리하는 방법을 결정해야 합니다.

다음과 같은 질문을 고려해야 합니다.

  • 고객의 ID 공급자에게 로그인을 페더레이션해야 합니까? 예를 들어 SAML, Microsoft Entra ID, 소셜 로그인 공급자 또는 기타 원본에 대한 페더레이션을 사용하도록 설정해야 하나요?
  • 사용자 또는 테넌트에 데이터 상주 요구 사항이 있나요?
  • 사용자가 둘 이상의 애플리케이션 테넌트에 액세스해야 하나요?
  • 복잡한 권한 및/또는 RBAC(역할 기반 액세스 제어)가 필요한가요?
  • 누가 애플리케이션에 로그인합니까? 다양한 범주의 사용자를 사용자 페르소나라고도 합니다.

다음 표에서는 Azure AD B2C에 대한 기본 테넌시 모델 간의 차이점을 요약합니다.

고려 사항 공유 Azure AD B2C 테넌트 수직 분할된 Azure AD B2C 테넌트 애플리케이션 테넌트당 하나의 Azure AD B2C 테넌트
데이터 격리 각 애플리케이션 테넌트에서의 데이터는 단일 Azure AD B2C 테넌트에 저장되지만 관리자만 액세스할 수 있습니다. 각 애플리케이션 테넌트에서의 데이터는 여러 Azure AD B2C 테넌트 간에 분산되지만 관리자만 액세스할 수 있습니다. 각 애플리케이션 테넌트에서의 데이터는 전용 Azure AD B2C 테넌트에 저장되지만 관리자만 액세스할 수 있습니다.
배포 복잡성 낮음 분할 전략에 따라 중간에서 높음 매우 높음
고려할 제한 사항 Azure AD B2C 테넌트당 요청, 클라이언트 IP 주소당 요청 분할 전략에 따라 요청, 구독당 Azure AD B2C 테넌트 수 및 단일 사용자에 대한 디렉터리 수의 조합 구독당 Azure AD B2C 테넌트 수, 단일 사용자에 대한 최대 디렉터리 수
운영 복잡성 낮음 분할 전략에 따라 중간에서 높음 매우 높음
필요한 Azure AD B2C 테넌트 수 하나 분할 전략에 따라 1에서 n 사이 n, 여기서 n은 애플리케이션 테넌트 수입니다.
예제 시나리오 음악 또는 비디오 스트리밍 서비스와 같이 데이터 상주 요구 사항이 낮거나 없는 소비자를 위한 SaaS 제품을 빌드하고 있습니다. 비즈니스용 회계 및 기록 보관 애플리케이션과 같은 SaaS 제품을 빌드하고 있습니다. 데이터 상주 요구 사항 또는 다수의 사용자 지정 페더레이션 ID 공급자를 지원해야 합니다. 기업용 정부 기록 보관 애플리케이션과 같은 SaaS 제품을 빌드하고 있습니다. 고객은 다른 애플리케이션 테넌트로부터 높은 수준의 데이터 격리를 의무화합니다.

공유 Azure AD B2C 테넌트

요구 사항이 허용되는 경우 일반적으로 단일 공유 Azure AD B2C 테넌트를 관리하는 것이 가장 쉽습니다. 기본 하나의 테넌트만 장기적으로 유지해야 하며, 이 옵션을 사용하면 오버헤드가 가장 낮습니다.

참고 항목

대부분의 시나리오에서는 공유 Azure AD B2C 테넌트를 사용하는 것이 좋습니다.

다음과 같은 경우 공유 Azure AD B2C 테넌트를 고려해야 합니다.

  • 데이터 상주 요구 사항 또는 엄격한 데이터 격리 요구 사항이 없습니다.
  • 애플리케이션 요구 사항은 Azure AD B2C 서비스 제한 내에 있습니다.
  • 페더레이션 ID 공급자가 있는 경우 홈 영역 검색을 사용하여 사용자가 로그인할 공급자를 자동으로 선택하거나 사용자가 목록에서 수동으로 선택할 수 있습니다.
  • 모든 애플리케이션 테넌트에 대한 통합 로그인 환경이 있습니다.
  • 최종 사용자는 단일 계정을 사용하여 둘 이상의 애플리케이션 테넌트에 액세스해야 합니다.

이 다이어그램은 공유 Azure AD B2C 테넌트 모델을 보여 줍니다.

단일 공유 Azure AD B2C 테넌트에 연결하는 세 개의 애플리케이션을 보여 주는 다이어그램.

수직 분할된 Azure AD B2C 테넌트

수직 분할된 Azure AD B2C 테넌트의 프로비전은 가능한 경우 필요한 Azure AD B2C 테넌트 수를 최소화하도록 설계된 전략입니다. 그것은 다른 테넌시 모델 사이의 중간 지점입니다. 수직 분할은 필요한 경우 특정 테넌트에 대한 사용자 지정에 더 큰 유연성을 제공합니다. 그러나 모든 애플리케이션 테넌트에 대해 Azure AD B2C 테넌트를 프로비전하는 것과 관련된 운영 오버헤드를 만들지는 않습니다.

이 테넌트 모델에 대한 배포 및 기본 테넌트 요구 사항은 단일 Azure AD B2C 테넌트보다 높지만 애플리케이션 테넌트당 하나의 Azure AD B2C 테넌트를 사용하는 경우보다 낮습니다. 환경 전반에 걸쳐 여러 테넌트에 대한 배포 및 기본 테넌트 전략을 설계하고 구현해야 합니다.

수직 분할은 데이터 분할 패턴과 유사합니다. Azure AD B2C 테넌트를 수직으로 분할하려면 애플리케이션 테넌트를 논리 그룹으로 구성해야 합니다. 이러한 테넌트 분류를 분할 전략이라고도 합니다. 분할 전략은 지역, 크기 또는 애플리케이션 테넌트의 사용자 지정 요구 사항과 같은 애플리케이션 테넌트의 공통적이고 안정적인 요소를 기반으로 해야 합니다. 예를 들어 데이터 상주 요구 사항을 해결하는 것이 목표인 경우 애플리케이션 테넌트를 호스트하는 각 지역에 대해 Azure AD B2C 테넌트를 배포하도록 결정할 수 있습니다. 또는 크기별로 그룹화하면 단일 Azure AD B2C 테넌트에서 대부분의 애플리케이션 테넌트 ID를 찾을 수 있지만 자체 전용 Azure AD B2C 테넌트에서 가장 큰 애플리케이션 테넌트를 찾을 수 있습니다.

Important

Azure AD B2C 테넌트 간에 사용자를 이동하기 어렵기 때문에 시간이 지남에 따라 변경될 수 있는 요인에 대한 분할 전략을 기반으로 하지 마세요. 예를 들어 여러 SKU 또는 제품 계층이 있는 SaaS 제품을 만드는 경우 고객이 제품을 업그레이드할 경우 SKU가 변경될 수 있으므로 선택한 SKU에 따라 사용자를 분할해서는 안 됩니다.

다음과 같은 경우 수직 분할 전략을 사용하여 Azure AD B2C 테넌트를 프로비전하는 것이 좋습니다.

  • 데이터 상주 요구 사항이 있거나 지리별로 사용자를 구분해야 합니다.
  • 많은 수의 페더레이션 ID 공급자가 있으며 홈 영역 검색을 사용하여 사용자가 로그인할 ID 공급자를 자동으로 선택할 수 없습니다.
  • 애플리케이션은 다중 테넌트를 인식하고 사용자가 로그인해야 하는 Azure AD B2C 테넌트를 알고 있습니다.
  • 더 큰 애플리케이션 테넌트가 Azure AD B2C 제한에 도달할 수 있다고 생각합니다.
  • 중간에서 많은 수의 Azure AD B2C 테넌트를 배포하고 기본 장기 전략을 가지고 있습니다.
  • 하나 이상의 Azure 구독 간에 애플리케이션 테넌트를 분할하여 Azure 구독에 배포할 수 있는 Azure AD B2C 테넌트 수 제한 내에서 작동하도록 하는 전략이 있습니다.

다음 다이어그램은 세로로 분할된 Azure AD B2C 테넌트 모델을 보여 줍니다.

세 가지 애플리케이션을 보여 주는 다이어그램 두 가지는 공유 Azure AD B2C 테넌트에 연결됩니다. 세 번째는 자체 Azure AD B2C 테넌트에 연결됩니다.

애플리케이션 테넌트당 하나의 Azure AD B2C 테넌트

각 애플리케이션 테넌트에 대해 Azure AD B2C 테넌트를 프로비전하는 경우 각 테넌트에 대한 여러 요소를 사용자 지정할 수 있습니다. 그러나 이 방법을 사용하면 오버헤드가 크게 증가합니다. 잠재적으로 많은 수의 Azure AD B2C 테넌트에 대한 배포 및 기본 테넌트 전략을 개발해야 합니다.

또한 서비스 제한을 알고 있어야 합니다. Azure 구독을 사용하면 제한된 수의 Azure AD B2C 테넌트만 배포할 수 있습니다. 허용되는 한도를 초과하여 배포해야 하는 경우 여러 구독에서 Azure AD B2C 테넌트 간에 균형을 맞출 수 있도록 적절한 구독 디자인을 고려해야 합니다. 단일 사용자가 만들 수 있는 디렉터리 수 및 사용자가 속할 수 있는 디렉터리 수와 같은 다른 Microsoft Entra 제한 도 적용됩니다.

Warning

이 방법의 복잡성 때문에 다른 격리 모델을 먼저 고려하는 것이 좋습니다. 이 옵션은 완전성을 위해 여기에 포함되어 있지만 대부분의 사용 사례에 적합한 방법은 아닙니다.

일반적인 오해는 배포 스탬프 패턴을 사용하는 경우 각 스탬프에 ID 서비스를 포함해야 한다고 가정하는 것입니다. 반드시 그런 것은 아니며 다른 격리 모델을 대신 사용할 수도 있습니다. 이 격리 모델을 사용하는 경우 실사를 수행하고 명확한 비즈니스 근거를 갖습니다. 배포 및 기본 테넌트 오버헤드는 중요합니다.

다음과 같은 경우에만 모든 애플리케이션 테넌트에 대해 Azure AD B2C 테넌트를 프로비전하는 것이 좋습니다.

  • 애플리케이션 테넌트에 대한 엄격한 데이터 격리 요구 사항이 있습니다.
  • 많은 수의 Azure AD B2C 테넌트를 배포하고 기본 장기 전략을 가지고 있습니다.
  • 구독당 Azure AD B2C 테넌트 제한을 준수하기 위해 하나 이상의 Azure 구독 간에 고객을 분할하는 전략이 있습니다.
  • 애플리케이션은 다중 테넌트를 인식하고 사용자가 로그인해야 하는 Azure AD B2C 테넌트를 알고 있습니다.
  • 모든 애플리케이션 테넌트에 대해 사용자 지정 구성을 수행해야 합니다.
  • 최종 사용자는 동일한 로그인 계정을 통해 둘 이상의 애플리케이션 테넌트에 액세스할 필요가 없습니다.

다음 다이어그램에서는 애플리케이션 테넌트당 하나의 Azure AD B2C 테넌트를 사용하는 방법을 보여 줍니다.

각각 자체 Azure AD B2C 테넌트에 연결하는 세 개의 애플리케이션을 보여 주는 다이어그램.

ID 페더레이션

사용자 흐름 또는 사용자 지정 정책을 통해 각 페더레이션 ID 공급자를 구성해야 합니다. 일반적으로 로그인하는 동안 사용자는 인증에 사용할 ID 공급자를 선택합니다. 공유 테넌트 격리 모델을 사용하거나 많은 수의 페더레이션 ID 공급자가 있는 경우 로그인하는 동안 홈 영역 검색을 사용하여 ID 공급자를 자동으로 선택하는 것이 좋습니다.

Id 페더레이션을 여러 Azure AD B2C 테넌트를 관리하는 도구로 Azure AD B2C 테넌트를 서로 페더레이션하여 사용할 수도 있습니다. 이렇게 하면 애플리케이션이 단일 Azure AD B2C 테넌트를 신뢰할 수 있습니다. 애플리케이션은 고객이 여러 Azure AD B2C 테넌트 간에 나뉘어져 있음을 인식할 필요가 없습니다. 이 방법은 사용자가 지역별로 분할될 때 수직으로 분할된 격리 모델에서 가장 일반적으로 사용됩니다. 이 접근 방식을 채택하는 경우 몇 가지 사항을 고려해야 합니다. 이 방법에 대한 개요는 글로벌 ID 솔루션을 참조 하세요.

홈 영역 검색

홈 영역 검색 은 사용자의 로그인 이벤트에 대한 페더레이션 ID 공급자를 자동으로 선택하는 프로세스입니다. 사용자의 ID 공급자를 자동으로 선택하는 경우 공급자를 선택하라는 메시지를 사용자에게 표시할 필요가 없습니다.

홈 영역 검색은 공유 Azure AD B2C 테넌트를 사용하고 고객이 자신의 페더레이션 ID 공급자를 가져올 수 있도록 허용하는 경우에 중요합니다. 사용자가 ID 공급자 목록에서 선택해야 하는 디자인을 방지할 수 있습니다. 이렇게 하면 로그인 프로세스가 복잡해집니다. 또한 사용자가 실수로 잘못된 공급자를 선택하면 로그인 시도가 실패할 수 있습니다.

다양한 방법으로 홈 영역 검색을 구성할 수 있습니다. 가장 일반적인 방법은 사용자 이메일 주소의 do기본 접미사를 사용하여 ID 공급자를 확인하는 것입니다. 예를 들어 Northwind Traders가 Fabrikam의 다중 테넌트 솔루션의 고객이라고 가정해 보겠습니다. 이메일 주소 user@northwindtraders.com 에는 Northwind Traders 페더레이션 ID 공급자에 매핑할 수 있는 do기본 접미사가 northwindtraders.com포함됩니다.

자세한 내용은 홈 영역 검색을 참조하세요. Azure AD B2C에서 이 방법을 구현하는 방법의 예제는 Azure AD B2C 샘플 GitHub 리포지토리를 참조 하세요.

데이터 보존

Azure AD B2C 테넌트를 프로비전할 때 테넌트를 배포할 지역인 데이터 보존을 위해 선택합니다. 이 선택은 고객 데이터가 미사용 상태일 때 상주하는 지역을 지정하기 때문에 중요합니다. 고객의 하위 집합에 대한 데이터 상주 요구 사항이 있는 경우 세로로 분할된 전략을 사용하는 것이 좋습니다.

권한 부여

강력한 ID 솔루션의 경우 인증 외에도 권한 부여를 고려해야 합니다. Microsoft ID 플랫폼 사용하여 애플리케이션에 대한 권한 부여 전략을 만드는 방법에는 여러 가지가 있습니다. AppRoles 샘플은 Azure AD B2C 앱 역할을 사용하여 애플리케이션에서 권한 부여를 구현하는 방법을 보여 줍니다. 또한 대체 권한 부여 방법을 설명합니다.

권한 부여에 대한 단일 접근 방식은 없으며, 접근 방식을 결정할 때 애플리케이션과 고객의 요구를 고려해야 합니다.

유지 관리

Azure AD B2C의 다중 테넌트 배포를 계획할 때는 Azure AD B2C 리소스의 장기 기본 테넌트에 대해 고려해야 합니다. 조직 Microsoft Entra 테넌트와 같은 Azure AD B2C 테넌트는 만들고, 기본, 작동하고, 보호해야 하는 리소스입니다. 다음 목록은 포괄적이지는 않지만 다음과 같은 영역에서 발생하는 기본 감쇠를 고려해야 합니다.

  • 테넌트 거버넌스. Azure AD B2C 테넌트는 누가 기본? 관리자에게 필요한 상승된 역할은 무엇인가요? 관리자에 대한 조건부 액세스 및 MFA 정책을 구성하려면 어떻게 해야 합니까? 장기적으로 Azure AD B2C 테넌트를 모니터링하려면 어떻게 해야 할까요?
  • 사용자 경험 구성. Azure AD B2C 테넌트 또는 테넌트에 변경 내용을 배포하려면 어떻게 해야 합니까? 사용자 흐름 또는 사용자 지정 정책을 배포하기 전에 변경 내용을 테스트하려면 어떻게 해야 할까요?
  • 페더레이션 ID 공급자입니다. 시간이 지남에 따라 ID 공급자를 추가하거나 제거해야 합니까? 각 고객이 자신의 ID 공급자를 가져오도록 허용하는 경우 대규모로 어떻게 관리하나요?
  • 앱 등록. 많은 Microsoft Entra 앱 등록은 인증에 클라이언트 암호 또는 인증서 를 사용합니다. 필요한 경우 이러한 비밀 또는 인증서를 어떻게 회전합니까?
  • 정책 키. 사용자 지정 정책을 사용하는 경우 필요할 때 정책 키를 어떻게 회전합니까?
  • 사용자 자격 증명. 사용자 정보 및 자격 증명을 관리하려면 어떻게 해야 합니까? 사용자 중 한 명이 잠겨 있거나 암호를 잊어버리고 관리자 또는 고객 서비스 개입이 필요한 경우 어떻게 되나요?

배포하는 모든 Azure AD B2C 테넌트에 대해 이러한 질문을 고려해야 합니다. 또한 여러 Azure AD B2C 테넌트가 기본 때 프로세스가 어떻게 변경되는지 고려해야 합니다. 예를 들어 사용자 지정 정책 변경 내용을 하나의 Azure AD B2C 테넌트에 수동으로 배포하는 것은 쉽지만 5개 테넌트에 수동으로 배포하는 것은 시간이 오래 걸리고 위험합니다.

배포 및 DevOps

잘 정의된 DevOps 프로세스를 사용하면 Azure AD B2C 테넌트를 기본 데 필요한 오버헤드를 최소화할 수 있습니다. 개발 프로세스 초기에 DevOps 사례를 구현해야 합니다. 사용자 지정 정책 또는 사용자 흐름에 변경 내용을 배포하는 것을 포함하여 기본 테넌트 작업의 전부 또는 대부분을 자동화하는 것이 가장 좋습니다. 또한 프로덕션 테넌트에 배포하기 전에 하위 환경에서 변경 내용을 점진적으로 테스트하기 위해 여러 Azure AD B2C 테넌트를 만들 계획입니다. DevOps 파이프라인은 이러한 기본 테넌트 작업을 수행할 수 있습니다. Microsoft Graph API를 사용하여 Azure AD B2C 테넌트를 프로그래밍 방식으로 관리할 수 있습니다.

Azure AD B2C의 자동화된 배포 및 관리에 대한 자세한 내용은 다음 리소스를 참조하세요.

Important

Azure AD B2C를 프로그래밍 방식으로 관리하는 데 사용되는 일부 엔드포인트는 일반적으로 사용할 수 없습니다. Microsoft Graph 베타 버전의 API는 언제든지 변경될 수 있으며 시험판 서비스 약관의 적용을 받습니다.

Microsoft Entra B2B와 Azure AD B2C 비교

Microsoft Entra B2B 협업은 게스트 사용자를 조직 Microsoft Entra 테넌트에 초대하는 데 사용할 수 있는 Microsoft Entra 외부 ID 기능입니다. 일반적으로 공급업체와 같은 외부 사용자에게 Microsoft Entra 테넌트에서 리소스에 대한 액세스 권한을 부여해야 하는 경우 B2B 협업을 사용합니다.

Microsoft Entra 외부 ID 조직 외부의 사용자와 상호 작용하는 데 사용할 수 있는 접근 방식 집합입니다. Azure AD B2C는 Microsoft Entra 외부 ID 기능 중 하나이지만 다른 외부 ID 접근 방식과는 다른 기능 집합을 제공합니다. Azure AD B2C는 제품의 고객이 사용합니다. Azure AD B2C 테넌트는 조직의 Microsoft Entra 테넌트와 다릅니다.

사용자 페르소나 및 시나리오에 따라 Microsoft Entra B2B, Azure AD B2C 또는 둘 다를 동시에 사용해야 할 수 있습니다. 예를 들어 애플리케이션이 동일한 앱 내에서 조직의 직원, 공급업체 및 고객을 위해 일하는 사용자와 같은 여러 유형의 사용자를 인증해야 하는 경우 Microsoft Entra B2B 및 Azure AD B2C를 함께 사용하여 이 요구 사항을 충족할 수 있습니다.

자세한 내용은 다음을 참조하세요.

참가자

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

보안 주체 작성자:

기타 기여자:

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

다음 단계