다중 테넌트 솔루션에서 ID에 대한 아키텍처 고려 사항

ID는 모든 다중 테넌트 솔루션의 중요한 측면입니다. 애플리케이션의 ID 구성 요소는 다음 작업을 담당합니다.

• 인증이라고 하는 사용자의 ID 확인

• 테넌트 범위 내에서 사용자의 권한 적용(권한 부여라고 함)

고객은 외부 애플리케이션이 데이터에 액세스하거나 솔루션과 통합할 수 있도록 권한을 부여하려고 할 수도 있습니다. 사용자 ID는 사용자 또는 서비스에서 액세스할 수 있는 정보를 결정합니다. 테넌트 간에 애플리케이션과 데이터를 격리하기 위해 ID 요구 사항을 고려하는 것이 중요합니다.

다중 테넌트 ID 전략을 정의하기 전에 먼저 서비스에 대해 다음과 같은 높은 수준의 ID 요구 사항을 고려합니다.

• 사용자 또는 워크로드 ID가 단일 애플리케이션에 액세스하는지 또는 제품 제품군 내의 여러 애플리케이션에 액세스하는지 확인합니다. 일부 제품 제품군에는 판매 시점 시스템 및 재고 관리 플랫폼과 같은 동일한 ID 인프라를 공유하는 고유한 애플리케이션이 포함될 수 있습니다.

• 솔루션이 OAuth2 및 OpenID Connect와 같은 최신 인증 및 권한 부여 표준을 구현하는지 여부를 고려합니다.

• 인증이 UI 기반 애플리케이션으로 제한되는지 또는 API 액세스가 테넌트 및 타사 시스템에도 적용되는지 평가합니다.

• 테넌트가 자체 IdP와 페더레이션해야 하는지 여부와 각 테넌트에 대해 여러 IdP를 지원해야 하는지 여부를 결정합니다. 예를 들어 각 테넌트가 솔루션과 페더레이션되는 Microsoft Entra ID, Auth0 및 Active Directory Federation Services를 사용하는 테넌트가 있을 수 있습니다. 해당 프로토콜이 IdP에서 지원해야 하는 사항을 결정하기 때문에 IdP가 사용하는 페더레이션 프로토콜을 식별합니다.

• ID 전략을 형성하는 GDPR(일반 데이터 보호 규정)과 같이 충족해야 하는 적용 가능한 규정 준수 요구 사항을 검토합니다.

• 테넌트가 법적, 규정 준수 또는 운영 요구 사항을 충족하기 위해 특정 지역에 ID 데이터를 저장해야 하는지 여부를 결정합니다.

• 사용자가 애플리케이션 내의 여러 테넌트에서 데이터에 액세스하는지 여부를 평가합니다. 이 경우 원활한 테넌트 전환을 지원하거나 특정 사용자에 대해 테넌트 간에 통합 보기를 제공해야 할 수 있습니다. 예를 들어 Azure Portal에 로그인하는 사용자는 서로 다른 Microsoft Entra ID 디렉터리와 액세스 권한이 있는 구독 간에 쉽게 전환할 수 있습니다.

높은 수준의 요구 사항을 설정하면 사용자 디렉터리 원본, 등록 및 로그인 흐름과 같은 보다 구체적인 세부 정보 및 요구 사항을 계획할 수 있습니다.

ID 디렉터리

다중 테넌트 솔루션이 사용자 또는 서비스를 인증하고 권한을 부여하려면 ID 정보를 저장할 장소가 필요합니다. 디렉터리에는 각 ID에 대한 신뢰할 수 있는 레코드가 포함될 수 있습니다. 또는 다른 IdP의 디렉터리에 저장된 외부 ID에 대한 참조를 포함할 수 있습니다.

다중 테넌트 솔루션에 대한 ID 시스템을 디자인할 때 테넌트와 고객에게 필요할 수 있는 다음 유형의 IdP를 고려해야 합니다.

• 로컬 IdP: 로컬 IdP를 사용하면 사용자가 서비스에 등록할 수 있습니다. 사용자는 사용자 이름, 이메일 주소 또는 식별자(예: 보상 카드 번호)를 제공합니다. 또한 암호와 같은 자격 증명을 제공합니다. IdP는 사용자 식별자와 자격 증명을 모두 저장합니다.

• 소셜 IdP: 소셜 IdP를 사용하면 사용자가 소셜 네트워크 또는 Facebook, Google 또는 개인 Microsoft 계정과 같은 다른 공용 IdP에 있는 ID를 사용할 수 있습니다. 소셜 IDP는 B2C(기업 간) SaaS 솔루션에서 일반적으로 사용됩니다.

• 테넌트의 Microsoft Entra ID 디렉터리: 많은 B2B(Business-to-Business) SaaS 솔루션에서 테넌트는 이미 자신만의 Microsoft Entra ID 디렉터리를 보유하고 있을 수 있으며, 솔루션에 대한 IdP로 해당 디렉터리를 사용하기를 원할 수 있습니다. 이 방법은 솔루션이 다중 테넌트 Microsoft Entra 애플리케이션으로 빌드되는 경우에 가능합니다.

• 테넌트의 IdP와 페더레이션: 일부 B2B SaaS 솔루션에서는 테넌트가 Microsoft Entra ID 이외의 고유한 IdP를 가지고 있을 수 있으며, 이들이 솔루션이 그 IdP와 페더레이션되기를 원할 수 있습니다. 페더레이션은 SSO(Single Sign-On)를 사용하도록 설정합니다. 또한 테넌트는 솔루션과 독립적으로 사용자의 수명 주기 및 보안 정책을 관리할 수 있습니다.

테넌트가 여러 IdP를 지원해야 하는지 고려해야 합니다. 예를 들어 단일 테넌트는 로컬 ID, 소셜 ID 및 페더레이션 ID를 지원해야 할 수 있습니다. 이 요구 사항은 회사에서 직원과 계약자 모두를 위한 솔루션을 사용하는 경우에 일반적입니다. 페더레이션을 사용하여 직원에게 액세스 권한을 부여하는 동시에 페더레이션 IdP에 계정이 없는 계약자 또는 사용자에 대한 액세스를 허용할 수 있습니다.

인증 및 테넌트 권한 부여 정보 저장

다중 테넌트 솔루션에서는 다음 형식을 포함하여 여러 유형의 ID 정보를 저장할 위치를 고려해야 합니다.

• 테넌트에 필요한 이름 및 기타 정보를 포함하여 사용자 및 서비스 계정에 대한 세부 정보입니다.

• MFA(다단계 인증) 정보를 포함하여 사용자를 안전하게 인증하는 데 필요한 정보입니다.

• 권한 부여를 위한 테넌트 역할 및 권한과 같은 테넌트 관련 정보입니다.

ID 정보를 저장하기 위해 다음 옵션을 고려합니다.

• IdP 디렉터리에 모든 ID 및 권한 부여 정보를 저장하고 여러 테넌트 간에 공유합니다.

• IdP 디렉터리에 사용자 자격 증명을 저장합니다. 테넌트 정보와 함께 애플리케이션 계층에 권한 부여 데이터를 저장합니다.

사용자의 ID 수 확인

다중 테넌트 솔루션을 사용하면 사용자 또는 워크로드 ID가 여러 테넌트의 애플리케이션 리소스 및 데이터에 액세스할 수 있습니다. 이 방법이 필요한 경우 다음 요소를 고려합니다.

• 각 사용자에 대해 단일 사용자 ID를 만들거나 각 테넌트-사용자 조합에 대해 별도의 ID를 만들 것인지 결정합니다.

  • 가능하면 각 사용자에 대해 단일 ID를 사용합니다. 솔루션 공급자와 사용자 모두에 대한 계정 관리를 간소화합니다. 또한 최신 IdP가 제공하는 많은 지능형 위협 보호는 단일 사용자 계정을 가진 각 사용자에게 의존합니다.

  • 일부 시나리오에서는 여러 고유 ID를 사용합니다. 예를 들어 사용자가 회사 및 개인용으로 시스템을 사용하는 경우 사용자 계정을 분리하고 싶을 수 있습니다. 또는 테넌트에 엄격한 규제 또는 지리적 데이터 스토리지 요구 사항이 있는 경우 규정 또는 법률을 준수할 수 있도록 여러 ID가 있어야 할 수 있습니다.

• 테넌트별 ID를 사용하는 경우 자격 증명을 여러 번 저장하지 않습니다. 사용자는 단일 ID에 대해 자격 증명을 저장해야 하며 게스트 ID와 같은 기능을 사용하여 여러 테넌트의 ID 레코드에서 동일한 사용자 자격 증명을 참조해야 합니다.

사용자에게 테넌트 데이터에 대한 액세스 권한 부여

사용자를 테넌트에 매핑하는 방법을 고려합니다. 예를 들어 등록 프로세스 중에 사용자가 처음으로 테넌트에 액세스할 때 입력할 수 있는 고유한 초대 코드를 제공할 수 있습니다. 일부 솔루션에서 사용자의 등록 전자 메일 주소의 도메인 이름은 연결된 테넌트 식별할 수 있습니다. 또는 사용자의 ID 레코드에서 다른 특성을 사용하여 테넌트 매핑을 결정할 수 있습니다. 그런 다음 이 연결은 테넌트와 사용자 모두에 대해 변경할 수 없는 고유 식별자를 기반으로 저장되어야 합니다.

솔루션이 각 사용자가 단일 테넌트에 대한 데이터에 액세스하도록 제한하는 경우 다음 결정을 고려합니다.

• IdP가 사용자가 액세스하는 테넌트를 검색하는 방법을 결정합니다.

• IdP가 테넌트 식별자를 애플리케이션과 통신하는 방법을 설명합니다. 일반적으로 테넌트 식별자 클레임이 토큰에 추가됩니다.

단일 사용자에게 여러 테넌트에 대한 액세스 권한을 부여해야 하는 경우 다음 결정을 고려합니다.

• 솔루션은 사용자를 식별하고 테넌트에 적절한 권한을 부여하는 논리를 지원해야 합니다. 예를 들어 사용자는 한 테넌트에서 관리 권한을 가지지만 다른 테넌트에서는 제한된 액세스 권한을 가질 수 있습니다. 예를 들어 사용자가 소셜 ID로 등록한 다음 두 개의 테넌트 액세스 권한을 부여했다고 가정합니다. 테넌트 A는 자세한 정보로 사용자의 ID를 보강했습니다. 테넌트 B가 보강된 정보에 액세스할 수 있어야 하나요?

• 명확한 메커니즘을 사용하면 사용자가 테넌트 간에 전환할 수 있습니다. 이 방법은 원활한 사용자 환경을 보장하고 실수로 테넌트 간 액세스를 방지합니다.

• 워크로드 ID를 사용하는 경우 액세스하려는 테넌트만 지정해야 합니다. 이 요구 사항에는 인증 요청에 테넌트별 컨텍스트 포함이 포함될 수 있습니다.

• 사용자의 ID 레코드에 저장된 테넌트별 정보가 의도치 않게 테넌트 간에 누출될 수 있는지 여부를 고려합니다. 예를 들어 사용자가 소셜 ID를 사용하여 등록하고 두 테넌트에 대한 액세스 권한을 얻고 테넌트 A가 사용자 프로필을 보강하는 경우 테넌트 B가 해당 보강 정보에 액세스할 수 있는지 여부를 결정합니다.

로컬 ID 또는 소셜 ID에 대한 사용자 등록 프로세스

일부 테넌트는 사용자가 솔루션의 ID에 등록하도록 허용해야 할 수 있습니다. 테넌트의 IdP와의 페더레이션이 필요하지 않은 경우 셀프 서비스 등록이 필요할 수 있습니다. 자체 등록 프로세스가 필요한 경우 다음 요소를 고려해야 합니다.

• 사용자가 등록할 수 있는 ID 원본을 정의합니다. 예를 들어 사용자가 로컬 ID를 만들고 소셜 IdP를 사용할 수 있는지 여부를 결정합니다.

• 로컬 ID가 사용되는 경우 솔루션에서 특정 전자 메일 도메인만 허용하는지 여부를 지정합니다. 예를 들어 테넌트가 전자 메일 주소를 가진 사용자 @contoso.com 에 대한 등록을 제한할 수 있는지 여부를 확인합니다.

• 로컬 ID를 식별하는 데 사용되는 UPN(사용자 계정 이름)을 명확하게 설정해야 합니다. 일반적인 UPN에는 전자 메일 주소, 사용자 이름, 전화 번호 또는 멤버 자격 식별자가 포함됩니다. UPN은 변경할 수 있으므로 권한 부여 및 감사를 위해 변경할 수 없는 기본 고유 식별자를 참조하는 것이 좋습니다. 예를 들어 Microsoft Entra ID의 OID(개체 ID)가 있습니다.

• UPN의 정확도를 보장하기 위해 확인이 필요할 수 있습니다. 이 프로세스에는 액세스 권한을 부여하기 전에 전자 메일 주소 또는 전화 번호의 소유권을 확인하는 작업이 포함될 수 있습니다.

• 일부 솔루션에서는 테넌트 관리자가 사용자 등록을 승인해야 할 수 있습니다. 이 승인 프로세스를 통해 테넌트에 조인하는 사용자를 관리할 수 있습니다.

• 테넌트별 가입 환경이나 URL이 필요한지 여부를 결정합니다. 예를 들어, 사용자가 등록할 때 테넌트에 브랜드화된 등록 경험이 필요한지, 또는 등록 요청을 가로채서 진행하기 전에 추가 유효성 검사를 수행할 수 있는지를 확인합니다.

자체 등록 사용자를 위한 테넌트 접근권한

사용자가 ID에 등록할 수 있는 경우 테넌트에 대한 액세스 권한을 부여하는 프로세스를 정의합니다. 등록 흐름에는 사용자에 대한 정보(예: 전자 메일 주소)를 기반으로 하는 수동 액세스 권한 부여 프로세스 또는 자동화된 프로세스가 포함될 수 있습니다. 이 프로세스를 계획하고 다음 요소를 고려하는 것이 중요합니다.

• 등록 흐름에서 사용자에게 특정 테넌트에 대한 액세스 권한이 부여되도록 결정하는 방법을 정의합니다.

• 솔루션이 적절한 경우 테넌트에 대한 사용자 액세스를 자동으로 취소할지 여부를 정의합니다. 예를 들어 사용자가 조직을 떠날 때 액세스를 제거하기 위한 수동 또는 자동화된 프로세스가 있어야 합니다.

• 테넌트가 환경에 액세스할 수 있는 사용자를 검토하고 할당된 권한을 이해할 수 있도록 사용자 감사 기능을 제공합니다.

자동화된 계정 수명 주기 관리

솔루션의 기업 또는 엔터프라이즈 고객을 위한 일반적인 요구 사항은 계정 온보딩 및 오프보딩을 자동화할 수 있는 기능 집합입니다. SCIM(도메인 간 ID 관리)에 대한 시스템과 같은 개방형 프로토콜은 자동화에 대한 업계 표준 접근 방식을 제공합니다. 이 자동화된 프로세스에는 일반적으로 ID 레코드 만들기 및 제거와 테넌트 권한 관리가 포함됩니다. 다중 테넌트 솔루션에서 자동화된 계정 수명 주기 관리를 구현할 때 다음 요소를 고려합니다.

• 고객이 각 테넌트에 대해 자동화된 수명 주기 프로세스를 구성하고 관리해야 하는지 여부를 결정합니다. 예를 들어 사용자가 온보딩되면 애플리케이션의 여러 테넌트 내에서 ID를 만들어야 할 수 있습니다. 여기서 각 테넌트는 다른 사용 권한 집합을 가집니다.

• SCIM을 구현해야 하는지 아니면 페더레이션을 제공해야 하는지 결정합니다. 페더레이션을 사용하면 테넌트가 솔루션에서 로컬 사용자를 관리하는 대신 자체 시스템 내에서 진실의 원본을 유지하여 사용자 관리에 대한 제어를 유지할 수 있습니다.

사용자 인증 프로세스

사용자가 다중 테넌트 애플리케이션에 로그인하면 ID 시스템이 사용자를 인증합니다. 인증 프로세스를 계획할 때 다음 요소를 고려합니다.

• 일부 테넌트에는 자체 MFA 정책을 구성하는 기능이 필요할 수 있습니다. 예를 들어 테넌트가 금융 서비스 업계에 있는 경우 엄격한 MFA 정책을 구현해야 하지만 소규모 온라인 소매점의 요구 사항은 동일하지 않을 수 있습니다.

• 사용자 지정 조건부 액세스 규칙을 정의하는 옵션은 테넌트에 중요할 수 있습니다. 예를 들어 다른 테넌트가 특정 지리적 영역의 로그인 시도를 차단해야 할 수 있습니다.

• 테넌트가 로그인 프로세스를 개별적으로 사용자 지정해야 하는지 여부를 결정합니다. 예를 들어 솔루션에 고객의 로고가 표시되어야 할 수 있습니다. 또는 다른 시스템에서 보상 번호와 같은 사용자 정보를 검색하고 IdP로 반환하여 사용자 프로필을 보강해야 할 수도 있습니다.

• 일부 사용자는 다른 사용자를 가장해야 할 수 있습니다. 예를 들어 지원 팀 구성원은 사용자로 인증하지 않고도 사용자 계정을 가장하여 다른 사용자가 가진 문제를 조사할 수 있습니다.

• 일부 사용자 또는 외부 애플리케이션에는 API 액세스가 필요할 수 있습니다. 이러한 시나리오에는 표준 사용자 인증 흐름을 우회하는 솔루션의 API를 직접 호출하는 것이 포함될 수 있습니다.

워크로드 신원

대부분의 솔루션에서 ID는 종종 사용자를 나타냅니다. 일부 다중 테넌트 시스템은 서비스 및 애플리케이션에서 워크로드 ID를 사용하여 애플리케이션 리소스에 액세스할 수 있도록 허용합니다. 예를 들어 테넌트는 관리 작업을 자동화할 수 있도록 솔루션이 제공하는 API에 액세스해야 할 수 있습니다.

Microsoft Entra는 워크로드 ID(아이덴티티)를 지원하며 다른 ID 제공자도 일반적으로 이를 지원합니다.

워크로드 ID는 사용자 ID와 유사하지만 일반적으로 키 또는 인증서와 같은 다른 인증 방법이 필요합니다. 워크로드 ID는 MFA를 사용하지 않습니다. 대신 워크로드 ID에는 일반적으로 일반 키 롤링 및 인증서 만료와 같은 다른 보안 제어가 필요합니다.

테넌트가 다중 테넌트 솔루션에 대한 워크로드 ID 액세스를 사용하도록 설정할 수 있는 경우 다음 요소를 고려해야 합니다.

• 각 테넌트에서 워크로드 ID를 만들고 관리하는 방법을 결정합니다.

• 워크로드 ID 요청의 범위를 테넌트로 지정하는 방법을 결정합니다.

• 각 테넌트가 만드는 워크로드 ID 수를 제한해야 하는지 평가합니다.

• 각 테넌트에서 워크로드 ID에 조건부 액세스 제어가 필요한지 확인합니다. 예를 들어 테넌트는 워크로드 ID가 특정 지역 외부에서 인증되지 않도록 제한하려고 할 수 있습니다.

• 워크로드 ID가 안전하게 유지되도록 테넌트에 제공하는 보안 제어를 식별합니다. 예를 들어 자동화된 키 롤링, 키 만료, 인증서 만료 및 로그인 위험 모니터링을 통해 워크로드 ID 오용 위험을 줄일 수 있습니다.

SSO용 IdP로 페더레이션

자체 사용자 디렉터리를 이미 보유한 테넌트는 솔루션이 해당 디렉터리와 페더레이션되기를 원할 수 있습니다. 페더레이션을 사용하면 솔루션이 별도의 디렉터리에서 고유한 ID를 관리하지 않고, 해당 디렉터리에 있는 ID를 사용할 수 있습니다.

페더레이션은 일부 테넌트가 자신의 ID 정책을 지정하거나 SSO 환경을 사용하도록 설정하려는 경우에 특히 중요합니다.

테넌트가 솔루션과 페더레이션되도록 예상하는 경우 다음 요소를 고려합니다.

• 테넌트에 대한 페더레이션을 구성하는 프로세스를 고려합니다. 테넌트가 페더레이션 자체를 구성하는지 또는 프로세스에 팀에서 수동 구성 및 유지 관리가 필요한지 확인합니다.

• 솔루션이 지원하는 페더레이션 프로토콜을 정의합니다.

• 페더레이션 잘못된 구성이 의도하지 않은 테넌트에 대한 액세스 권한을 부여하지 못하도록 하는 프로세스를 설정합니다.

• 솔루션 내에서 단일 테넌트의 IdP를 둘 이상의 테넌트에 연동시켜야 하는지를 계획하십시오. 예를 들어 고객에게 교육 및 프로덕션 테넌트가 모두 있는 경우 각 테넌트와 동일한 IdP를 페더레이션해야 할 수 있습니다.

권한 부여 모델

솔루션에 가장 적합한 권한 부여 모델을 결정합니다. 다음과 같은 일반적인 권한 부여 방법을 고려합니다.

• 역할 기반 권한 부여: 사용자는 역할에 할당됩니다. 애플리케이션의 일부 기능은 특정 역할로 제한됩니다. 예를 들어 관리자 역할의 사용자는 모든 작업을 수행할 수 있지만 하위 역할의 사용자는 시스템 전체에서 사용 권한의 하위 집합을 가질 수 있습니다.

• 리소스 기반 권한 부여: 솔루션은 고유한 리소스 집합을 제공하며 각 리소스에는 고유한 권한 집합이 있습니다. 특정 사용자는 한 리소스의 관리자일 수 있으며 다른 리소스에 액세스할 수 없습니다.

이러한 모델은 고유하며 선택하는 접근 방식은 구현 및 구현할 수 있는 권한 부여 정책의 복잡성에 영향을 줍니다.

권한 및 라이선스

일부 솔루션에서는 상업용 가격 책정 모델의 일부로 사용자별 라이선스를 사용할 수 있습니다. 이 시나리오에서는 기능이 다른 다양한 사용자 라이선스 계층을 제공합니다. 예를 들어 라이선스가 하나 있는 사용자는 애플리케이션 기능의 하위 집합을 사용하도록 허용될 수 있습니다. 특정 사용자가 라이선스에 따라 액세스할 수 있는 기능을 권한이라고도 합니다.

애플리케이션 코드 또는 전용 권한 시스템은 일반적으로 ID 시스템 대신 자격을 추적하고 적용합니다. 이 프로세스는 권한 부여와 유사하지만 ID 관리 계층 외부에서 발생합니다.

ID 크기 조정 및 인증 볼륨

다중 테넌트 솔루션이 증가함에 따라 솔루션에서 처리해야 하는 사용자 및 로그인 요청 수가 증가합니다. 다음 사항을 고려합니다.

• 사용자 디렉터리가 필요한 사용자 수를 지원하도록 확장되는지 여부를 평가합니다.

• 인증 프로세스가 예상되는 로그인 및 등록 수를 처리하는지 여부를 평가합니다.

• 인증 시스템에서 처리할 수 없는 급증이 있는지 여부를 확인합니다. 예를 들어 태평양 표준시 오전 9시에 미국 서부의 모든 사용자가 작업을 시작하고 솔루션에 로그인하여 로그인 요청이 급증할 수 있습니다. 이러한 시나리오를 로그인 폭풍이라고도 합니다.

• 솔루션의 일부에서 높은 부하가 인증 프로세스의 성능에 영향을 주는지 여부를 확인합니다. 예를 들어 인증에 애플리케이션 계층 API를 호출해야 하는 경우 인증 요청이 급증하면 전반적인 시스템 성능에 영향을 줄 수 있습니다.

• IdP를 사용할 수 없게 되면 솔루션의 동작 방식을 정의합니다. 비즈니스 연속성을 유지하기 위해 백업 인증 서비스를 포함해야 하는지 여부를 고려합니다.

기여자

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

주요 작성자:

• John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
• Daniel Scott-Raynsford | 파트너 기술 전략가
• Arsen Vladimirskiy | 수석 고객 엔지니어, FastTrack for Azure

기타 기여자:

• Jelle Druyts | 수석 고객 엔지니어, FastTrack for Azure
• Landon Pierce | 선임 고객 엔지니어
• Sander van den Hoven | 선임 파트너 기술 전략가
• Nick Ward | 선임 클라우드 솔루션 설계자

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

관련 리소스

• 다중 테넌트 솔루션의 ID에 대한 아키텍처 접근 방식