다음을 통해 공유

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

  • 아티클

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

  • 사용자가 누구인지 확인(인증).
  • 테넌트 범위 내에서 사용자의 사용 권한 적용(권한 부여)

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

주의

다중 테넌트 및 SaaS 애플리케이션 내에서 인증 및 권한 부여 서비스는 일반적으로 IdP(타사 ID 공급자)가 제공합니다. ID 공급자는 일반적으로 IDaaS(ID as a Service) 플랫폼의 필수적인 부분입니다.

고유한 IdP를 빌드하는 것은 복잡하고 비용이 많이 들며 안전하게 빌드하기 어렵습니다. 고유한 ID 공급자를 빌드하는 것은 안티패턴입니다. 이는 권장되지 않습니다.

다중 테넌트 ID 전략을 정의하기 전에 먼저 다음 요구 사항을 포함하여 서비스의 상위 수준 ID 요구 사항을 고려해야 합니다.

  • 사용자 또는 워크로드 ID를 사용하여 단일 애플리케이션 또는 제품 제품군 내의 여러 애플리케이션에 액세스할 수 있나요? 예를 들어 소매 제품 제품군에는 동일한 ID 솔루션을 공유하는 POS(point-of-sale) 애플리케이션과 재고 관리 애플리케이션이 모두 있을 수 있습니다.
  • OAuth2 및 OpenID Connect와 같은 최신 인증 및 권한 부여를 구현할 계획입니까?
  • 솔루션이 UI 기반 애플리케이션에만 인증을 제공하나요? 또는 테넌트 및 타사에 대한 API 액세스 권한도 제공합니까?
  • 테넌트는 자신의 IdP에 페더레이션해야 하며 각 테넌트마다 여러 ID 공급자를 지원해야 합니까? 예를 들어 Microsoft Entra ID, Auth0 및 ADFS(Active Directory Federation Services)가 있는 테넌트가 있을 수 있습니다. 여기서 각 테넌트는 솔루션과 페더레이션하려고 합니다. 또한 프로토콜이 사용자 고유의 IdP 요구 사항에 영향을 주므로 지원할 테넌트 IDP의 페더레이션 프로토콜도 이해해야 합니다.
  • GDPR과 같이 충족해야 하는 특정 규정 준수 요구 사항이 있나요?
  • 테넌트에서 자신의 ID 정보가 특정 지역에 위치하도록 요구합니까?
  • 솔루션 사용자는 한 테넌트 또는 애플리케이션 내의 여러 테넌트에서 데이터에 액세스해야 하나요? 테넌트 간에 빠르게 전환하거나 여러 테넌트에서 통합 정보를 볼 수 있는 기능이 필요한가요? 예를 들어 Azure Portal에 로그인한 사용자는 액세스 권한이 있는 다른 Microsoft Entra ID 디렉터리와 구독 간에 쉽게 전환할 수 있습니다.

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

ID 디렉터리

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

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

  • 로컬 ID 공급자 로컬 ID 공급자를 사용하면 사용자가 서비스에 직접 로그인할 수 있습니다. 사용자는 사용자 이름, 이메일 주소 또는 식별자(예: 보상 카드 번호)를 제공합니다. 또한 암호와 같은 자격 증명을 제공합니다. IdP는 사용자 식별자와 자격 증명을 모두 저장합니다.
  • 소셜 ID 공급자 소셜 ID 공급자를 사용하면 사용자가 Facebook, Google 또는 개인 Microsoft 계정과 같은 소셜 네트워크 또는 기타 공용 ID 공급자에 있는 ID를 사용할 수 있습니다.
  • 테넌트의 Microsoft Entra ID 디렉터리를 사용합니다. 테넌트는 이미 고유한 Microsoft Entra ID 디렉터리를 가지고 있을 수 있으며 솔루션에 액세스하기 위해 솔루션이 자신의 디렉터리를 IdP로 사용하려고 할 수 있습니다. 이 방법은 솔루션이 다중 테넌트 Microsoft Entra 애플리케이션으로 빌드되는 경우에 가능합니다.
  • 테넌트의 ID 공급자를 사용한 페더레이션 테넌트는 Microsoft Entra ID 이외의 고유한 IdP를 가질 수 있으며 솔루션이 페더레이션되기를 원할 수 있습니다. 페더레이션을 사용하면 SSO(Single Sign-On) 환경을 사용할 수 있으며 테넌트는 솔루션과 독립적으로 사용자의 수명 주기 및 보안 정책을 관리할 수 있습니다.

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

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

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

  • 테넌트에서 요구하는 이름 및 기타 정보 등 사용자 및 서비스 계정에 대한 세부 정보입니다.
  • MFA(다단계 인증)를 제공하는 데 필요한 정보 등 사용자를 안전하게 인증하는 데 필요한 정보입니다.
  • 테넌트 역할 및 권한과 같은 테넌트 관련 정보입니다. 이 정보는 권한 부여에 사용됩니다.

주의

인증 프로세스를 직접 빌드하지 않는 것이 좋습니다. 최신 IdP는 애플리케이션에 이러한 인증 서비스를 제공하며 MFA 및 조건부 액세스와 같은 다른 중요한 기능도 포함합니다. 고유한 ID 공급자를 빌드하는 것은 안티패턴입니다. 이는 권장되지 않습니다.

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

  • IdP 디렉터리에 모든 ID 및 권한 부여 정보를 저장하고 여러 테넌트 간에 공유합니다.
  • IdP 디렉터리에 사용자 자격 증명을 저장하고 테넌트 정보와 함께 애플리케이션 계층에 권한 부여 정보를 저장합니다.

사용자의 ID 수 확인

다중 테넌트 솔루션은 사용자 또는 워크로드 ID가 여러 테넌트의 애플리케이션 및 데이터에 액세스할 수 있도록 허용하는 것이 일반적입니다. 솔루션에 이 접근 방식이 필요한지 여부를 고려합니다. 그렇다면 다음 질문을 고려해야 합니다.

  • 각 사용자에 대해 단일 사용자 ID를 만들거나 각 테넌트-사용자 조합에 대해 별도의 ID를 만들어야 하나요?
    • 가능한 경우 각 사용자에 대해 단일 ID를 사용하는 것이 가장 좋습니다. 솔루션 공급업체와 사용자 모두에 대해 여러 사용자 계정을 관리하기가 어려워집니다. 또한 최신 IdP에서 제공하는 많은 지능형 위협 방지는 단일 사용자 계정을 가진 각 사용자에게 의존합니다.
    • 그러나 경우에 따라 사용자가 여러 개의 고유 ID를 가져야 할 수 있습니다. 예를 들어 사용자가 회사 및 개인용으로 시스템을 사용하는 경우 사용자 계정을 분리하고 싶을 수 있습니다. 또는 테넌트가 엄격한 규제 또는 지리적 데이터 스토리지 요구 사항이 있는 경우 규정 또는 법률을 준수할 수 있도록 사용자에게 여러 ID를 요구할 수 있습니다.
  • 테넌트별 ID를 사용하는 경우 자격 증명을 여러 번 저장하지 마십시오. 사용자는 단일 ID에 대해 자격 증명을 저장해야 하며 게스트 ID와 같은 기능을 사용하여 여러 테넌트의 ID 레코드에서 동일한 사용자 자격 증명을 참조해야 합니다.

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

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

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

  • IdP에서 사용자가 액세스하는 테넌트는 어떻게 감지하나요?
  • IdP는 테넌트 식별자를 애플리케이션에 어떻게 전달하나요? 일반적으로 테넌트 식별자 클레임이 토큰에 추가됩니다.

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

  • 솔루션은 여러 테넌트 액세스 권한이 있는 사용자에게 권한을 어떻게 식별하고 부여하나요? 예를 들어 사용자가 학습 테넌트에서 관리자이고 프로덕션 테넌트에 대해 읽기 전용으로 액세스할 수 있나요? 또는 조직의 여러 부서에 대해 별도의 테넌트를 가질 수 있지만 모든 테넌트에서 일관된 사용자 ID를 유지해야 하나요?
  • 사용자는 테넌트 간에 어떻게 전환하나요?
  • 워크로드 ID를 사용하는 경우 워크로드 ID에서 액세스해야 하는 테넌트는 어떻게 지정하나요?
  • 테넌트 간에 정보를 유출할 수 있는 사용자의 ID 레코드에 테넌트별 정보가 저장되어 있나요? 예를 들어 사용자가 소셜 ID로 등록한 다음 두 개의 테넌트 액세스 권한을 부여했다고 가정합니다. 테넌트 A는 자세한 정보로 사용자의 ID를 보강했습니다. 테넌트 B가 보강된 정보에 액세스할 수 있어야 하나요?

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

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

  • 사용자가 등록할 수 있는 ID 원본은 무엇입니까? 예를 들어 사용자가 로컬 ID를 만들고 소셜 ID 공급자도 사용할 수 있나요?
  • 로컬 ID만 허용되는 경우 특정 전자 메일 도메인만 허용되나요? 예를 들어 테넌트는 @contoso.com 이메일 주소가 있는 사용자만 등록하도록 지정할 수 있나요?
  • 로그인 프로세스 중에 각 로컬 ID를 고유하게 식별하는 데 사용해야 하는 UPN(사용자 계정 이름)은 무엇인가요? 예를 들어 이메일 주소, 사용자 이름, 전화 번호 및 보상 카드 번호는 모두 일반적으로 UPN으로 사용할 수 있습니다. 그러나 UPN은 시간이 지나면 변경될 수 있습니다. 애플리케이션의 권한 부여 규칙 또는 감사 로그에서 ID를 참조하는 경우 ID의 변경할 수 없는 기본 고유 ID를 사용하는 것이 좋습니다. Microsoft Entra ID는 변경할 수 없는 ID인 OID(개체 ID)를 제공합니다.
  • 사용자가 UPN을 확인해야 합니까? 예를 들어 사용자의 이메일 주소 또는 전화 번호가 UPN으로 사용되는 경우 정보가 정확한지 어떻게 확인하나요?
  • 테넌트 관리자가 등록을 승인해야 합니까?
  • 테넌트에서 테넌트별 등록 환경 또는 URL이 필요한가요? 예를 들어 사용자가 등록할 때 테넌트에서 브랜드 등록 환경을 요구하나요? 테넌트에 등록 요청을 가로채고 계속 진행하기 전에 추가 유효성 검사를 수행하는 기능이 필요한가요?

자체 등록 사용자에 대한 테넌트 액세스

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

  • 등록 흐름에서 사용자에게 특정 테넌트 액세스 권한을 부여해야 한다고 결정하려면 어떻게 해야 하나요?
  • 사용자가 더 이상 테넌트에 대한 액세스 권한을 가져서는 안 되는 경우 솔루션이 자동으로 액세스 권한을 취소하나요? 예를 들어 사용자가 조직을 떠날 때 테넌트에서 액세스 권한을 제거하는 수동 또는 자동화된 프로세스가 있어야 합니다.
  • 테넌트가 테넌트 및 해당 권한에 액세스할 수 있는 사용자를 감사할 수 있는 방법을 제공해야 합니까?

자동 계정 수명 주기 관리

일반적으로 회사 또는 기업 고객이 솔루션을 이용하려면 계정 온보딩 및 오프보딩을 자동화할 수 있는 기능 집합이 필요합니다. SCIM(System for Cross-domain Identity Management)과 같은 개방형 프로토콜은 자동화에 대한 업계 표준 접근 방식을 제공합니다. 이 자동화된 프로세스에는 일반적으로 ID 레코드 만들기 및 제거뿐만 아니라 테넌트 권한 관리도 포함됩니다. 다중 테넌트 솔루션에서 자동화된 계정 수명 주기 관리를 구현할 때 다음 질문을 고려합니다.

  • 고객이 각 테넌트에 대해 자동화된 수명 주기 프로세스를 구성하고 관리해야 합니까? 예를 들어 사용자가 온보딩되면 애플리케이션의 여러 테넌트 내에서 ID를 만들어야 할 수 있습니다. 여기서 각 테넌트는 다른 사용 권한 집합을 가집니다.
  • SCIM을 구현해야 합니까? 아니면 로컬 사용자를 관리하는 대신 테넌트가 제어하는 사용자에 대한 진실의 출처를 유지하기 위해 테넌트 페더레이션을 대신 제공할 수 있나요?

사용자 인증 프로세스

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

  • 테넌트가 자체 MFA(다단계 인증) 정책을 구성해야 합니까? 예를 들어 테넌트가 금융 서비스 업계에 있는 경우 엄격한 MFA 정책을 구현해야 하지만 소규모 온라인 소매점의 요구 사항은 동일하지 않을 수 있습니다.
  • 테넌트가 자체 조건부 액세스 규칙을 구성해야 합니까? 예를 들어 다른 테넌트가 특정 지리적 영역의 로그인 시도를 차단해야 할 수 있습니다.
  • 테넌트가 각 테넌트에서 로그인 프로세스를 사용자 지정해야 합니까? 예를 들어 고객의 로고를 표시해야 합니까? 또는 각 사용자에 대한 정보를 보상 번호와 같은 다른 시스템에서 추출하고 ID 공급자에게 반환하여 사용자 프로필에 추가해야 합니까?
  • 사용자가 다른 사용자를 가장해야 합니까? 예를 들어 지원 팀 구성원은 사용자로 인증할 필요 없이 사용자 계정을 가장하여 다른 사용자가 가지고 있는 문제를 조사하고 싶을 수 있습니다.
  • 사용자가 솔루션을 위해 API에 액세스해야 합니까? 예를 들어 사용자 또는 타사 애플리케이션은 인증 흐름을 제공하기 위해 사용자 인터페이스 없이 솔루션을 확장할 수 있도록 API를 직접 호출해야 할 수 있습니다.

워크로드 ID

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

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

테넌트가 다중 테넌트 솔루션에 대한 워크로드 ID 액세스를 사용할 것으로 예상되는 경우 다음 질문을 고려해야 합니다.

  • 워크로드 ID는 각 테넌트에서 어떻게 만들어지고 관리되나요?
  • 워크로드 ID 요청의 범위는 어떻게 테넌트로 지정되나요?
  • 각 테넌트에서 만든 워크로드 ID의 수를 제한해야 합니까?
  • 각 테넌트에서 워크로드 ID에 대한 조건부 액세스 제어를 제공해야 합니까? 예를 들어 테넌트는 워크로드 ID가 특정 지역 외부에서 인증되지 않도록 제한하려고 할 수 있습니다.
  • 워크로드 ID를 안전하게 유지하기 위해 테넌트에게 제공할 보안 제어는 무엇인가요? 예를 들어 자동화된 키 롤링, 키 만료, 인증서 만료 및 로그인 위험 모니터링은 모두 워크로드 ID가 오용될 수 있는 위험을 줄이는 방법입니다.

SSO(Single Sign-On)를 위해 ID 공급자와 페더레이션

자체 사용자 디렉터리를 이미 보유한 테넌트는 솔루션이 해당 디렉터리에 페더레이션되도록 할 수 있습니다. 페더레이션을 사용하면 솔루션이 고유한 ID를 사용하여 다른 디렉터리를 관리하는 대신 해당 디렉터리의 ID를 사용할 수 있습니다.

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

테넌트가 솔루션과 페더레이션할 것으로 예상되는 경우 다음 질문을 고려해야 합니다.

  • 테넌트용 페더레이션을 구성하는 프로세스는 무엇인가요? 테넌트가 페더레이션 자체를 구성할 수 있나요, 아니면 팀에서 수동으로 구성하고 유지 관리해야 하나요?
  • 어떤 페더레이션 프로토콜을 지원하시겠습니까?
  • 페더레이션을 잘못 구성할 수 없도록 하고 다른 테넌트에게 액세스 권한을 부여하기 위한 프로세스는 무엇인가요?
  • 솔루션에서 단일 테넌트의 ID 공급자를 둘 이상의 테넌트로 페더레이션해야 하나요? 예를 들어 고객에게 교육 및 프로덕션 테넌트가 모두 있는 경우 동일한 ID 공급자를 두 테넌트 모두에 페더레이션해야 할 수 있습니다.

권한 부여 모델

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

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

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

권한 및 라이선스

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

권한 추적 및 적용은 권한 부여와 유사하지만 일반적으로 ID 시스템에서 관리하지 않고 애플리케이션 코드 또는 전용 권한 시스템에 의해 처리됩니다.

ID 크기 조정 및 인증 볼륨

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

  • 사용자 디렉터리가 필요한 사용자 수로 확장될까요?
  • 인증 프로세스에서 예상되는 로그인 및 등록 수를 처리합니까?
  • 인증 시스템에서 처리할 수 없는 급증이 있나요? 예를 들어 오전 9시 PST에 미국 서부 지역의 모든 사용자가 작업을 시작하고 솔루션에 로그인하여 로그인 요청이 급증할 수 있습니다. 이러한 상황을 로그인 스톰이라고도 합니다.
  • 솔루션의 다른 부분에서 나타나는 높은 부하가 인증 프로세스의 성능에 영향을 미칠 수 있나요? 예를 들어 인증 프로세스에서 애플리케이션 계층 API를 호출해야 하는 경우 인증 요청 수가 많으면 나머지 솔루션에 문제가 발생합니까?
  • IdP를 사용할 수 없게 되면 어떻게 되나요? IdP를 사용할 수 없는 동안 비즈니스 연속성을 제공하기 위해 인수할 수 있는 백업 인증 서비스가 있나요?

참가자

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

주요 작성자:

기타 기여자:

다음 단계

다중 테넌트 솔루션의 ID에 대한 아키텍처 접근 방식을 검토합니다.