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

  • 아티클

거의 모든 다중 테넌트 솔루션에는 ID 시스템이 필요합니다. 이 문서에서는 인증 및 권한 부여 모두를 포함하여 ID의 일반적인 구성 요소에 대해 설명하고, 이러한 구성 요소를 다중 테넌트 솔루션에 적용할 수 있는 방법에 대해 설명합니다.

참고

다중 테넌트 솔루션에 대한 ID 시스템 구축을 시작하기 전에 먼저 다중 테넌트 솔루션의 ID에 대한 아키텍처 고려 사항을 검토하여 필요한 주요 요구 사항 및 결정에 대해 자세히 알아보세요.

인증

인증은 사용자의 ID를 설정하는 프로세스입니다. 다중 테넌트 솔루션을 구축하는 경우 인증 프로세스의 몇 가지 측면에 대한 특별한 고려 사항과 접근 방식이 있습니다.

페더레이션

다른 IdP(ID 공급자)와 페더레이션해야 할 수도 있습니다. 페더레이션을 사용하여 사용하도록 설정할 수 있는 시나리오는 다음과 같습니다.

  • 소셜 로그인(예: 사용자가 Google, Facebook, GitHub 또는 개인 Microsoft 계정을 사용할 수 있도록 하는 것)
  • 테넌트별 디렉터리(예: 테넌트에서 여러 위치에 있는 계정을 관리할 필요가 없도록 테넌트에서 자체의 ID 공급자와 애플리케이션을 페더레이션할 수 있도록 하는 것)

페더레이션에 대한 일반적인 내용은 페더레이션 ID 패턴을 참조하세요.

테넌트별 ID 공급자를 지원하도록 선택하는 경우 지원해야 하는 서비스 및 프로토콜을 명확히 해야 합니다. 예를 들어 OpenID Connect 프로토콜과 SAML(Security Assertion Markup Language) 프로토콜을 지원할 수 있나요? 또는 Microsoft Entra 인스턴스와의 페더레이션만 지원합니까?

자격 증명 공급자를 구현할 때 적용할 수 있는 크기와 제한을 고려합니다. 예를 들어 Azure AD(Azure Active Directory) B2C를 사용자 고유의 ID 공급자로 사용하는 경우 특정 유형의 테넌트 ID 공급자와 페더레이션하는 사용자 지정 정책을 배포해야 할 수 있습니다. Azure AD B2C는 배포할 수 있는 사용자 지정 정책의 수를 제한하므로 페더레이션할 수 있는 테넌트별 ID 공급자의 수가 제한될 수 있습니다.

또한 페더레이션을 더 높은 제품 계층의 고객에게만 적용되는 기능으로 제공하는 것도 고려할 수 있습니다.

Single Sign-On

Single Sign-On 환경을 사용하면 각 지점에서 다시 인증하라는 메시지가 표시되지 않고도 사용자가 애플리케이션 간에 원활하게 전환할 수 있습니다.

사용자가 애플리케이션을 방문하면 애플리케이션이 IdP로 전달됩니다. IdP에서 기존 세션이 있다고 확인하면 사용자가 로그인 프로세스와 상호 작용할 필요 없이 새 토큰을 발급합니다. 페더레이션 ID 모델은 사용자가 여러 애플리케이션에서 단일 ID를 사용할 수 있도록 하여 Single Sign-On 환경을 지원합니다.

다중 테넌트 솔루션에서는 다른 형태의 Single Sign-On을 사용하도록 설정할 수도 있습니다. 사용자가 여러 테넌트에서 데이터를 사용할 수 있는 권한이 있는 경우 사용자가 컨텍스트를 한 테넌트에서 다른 테넌트로 변경할 때 원활한 환경을 제공해야 할 수 있습니다. 테넌트 간의 원활한 전환을 지원해야 하는지 여부 및 지원해야 하는 ID 공급자가 토큰을 특정 테넌트 클레임으로 다시 발급해야 하는지 여부를 고려합니다. 예를 들어 Azure Portal에 로그인한 사용자는 다른 Microsoft Entra 디렉터리 간에 전환하여 재인증할 수 있으며 새로 선택한 Microsoft Entra 인스턴스에서 토큰을 재발행합니다.

로그인 위험 평가

최신 ID 플랫폼은 로그인 프로세스 중에 위험을 평가하도록 지원합니다. 예를 들어 사용자가 비정상적인 위치 또는 디바이스에서 로그인하는 경우 로그인 요청을 진행하기 전에 인증 시스템에서 MFA(다단계 인증)와 같은 추가 ID 확인을 요구할 수 있습니다.

인증 프로세스 중에 적용해야 하는 다른 위험 정책이 테넌트에 있는지 여부를 고려합니다. 예를 들어 일부 테넌트가 엄격한 규제를 받는 산업에 있는 경우 비교적 규제가 심하지 않은 환경에서 작업하는 테넌트와 다른 위험 프로필 및 요구 사항이 있을 수 있습니다. 또는 더 높은 가격 책정 계층의 테넌트에서 더 낮은 서비스 계층을 구매하는 테넌트보다 더 제한적인 로그인 정책을 지정하도록 허용할 수 있습니다.

각 테넌트마다 서로 다른 위험 정책을 지원해야 하는 경우 인증 시스템은 올바른 정책을 적용할 수 있도록 사용자가 로그인하는 테넌트를 인식하고 있어야 합니다.

이러한 기능이 IdP에 포함되는 경우 IdP의 기본 로그인 위험 평가 기능을 사용하는 것이 좋습니다. 이러한 기능을 직접 구현하는 경우 복잡하고 오류가 발생하기 쉽습니다.

또는 테넌트의 자체 ID 공급자와 페더레이션하는 경우 자체의 위험한 로그인 완화 정책을 적용할 수 있으며, 적용해야 하는 정책 및 제어를 제어할 수 있습니다. 그러나 두 가지 MFA 챌린지(사용자의 홈 ID 공급자 및 사용자 고유의 ID 공급자 각각으로부터의 챌린지)를 요구하는 것과 같이 실수로 불필요한 부담을 사용자에게 지우지 않도록 하는 것이 중요합니다. 페더레이션이 각 테넌트의 ID 공급자 및 적용한 정책과 상호 작용하는 방식을 이해해야 합니다.

가장

가장을 통해 사용자는 해당 사용자의 자격 증명을 사용하지 않고 다른 사용자의 ID를 가정할 수 있습니다.

일반적으로 가장은 위험하며, 구현하고 제어하기가 어려울 수 있습니다. 그러나 일부 시나리오에서는 가장이 요구 사항입니다. 예를 들어 SaaS(Software as a Service)를 운영하는 경우 기술 지원팀 직원이 사용자로 로그인하여 문제를 해결할 수 있도록 사용자의 ID를 가정해야 할 수 있습니다.

가장을 구현하도록 선택한 경우 해당 사용을 감사하는 방법을 고려합니다. 로그는 작업을 수행한 실제 사용자와 가장한 사용자의 식별자를 모두 포함해야 합니다.

일부 ID 플랫폼은 기본 제공 기능으로 또는 사용자 지정 코드를 사용하여 가장을 지원합니다. 예를 들어 Azure AD B2C에서 가장된 사용자 ID에 대한 사용자 지정 클레임을 추가하거나 발급된 토큰에서 주체 식별자 클레임을 바꿀 수 있습니다.

권한 부여

권한 부여는 사용자가 수행할 수 있는 작업을 결정하는 프로세스입니다.

권한 부여 데이터는 다음 위치를 포함하여 여러 위치에 저장할 수 있습니다.

  • ID 공급자. 예를 들어 Microsoft Entra ID를 ID 공급자로 사용하는 경우 앱 역할 및 그룹과 같은 기능을 사용하여 권한 부여 정보를 저장할 수 있습니다. 그런 다음, 애플리케이션에서 연결된 토큰 클레임을 사용하여 권한 부여 규칙을 적용할 수 있습니다.
  • 사용자의 애플리케이션에서 사용자 고유의 권한 부여 논리를 작성한 다음, 각 사용자가 수행할 수 있는 작업에 대한 정보를 데이터베이스 또는 이와 비슷한 스토리지 시스템에 저장할 수 있습니다. 그런 다음, 역할 기반 또는 리소스 수준 권한 부여에 대한 세분화된 제어를 설계할 수 있습니다.

대부분의 다중 테넌트 솔루션에서 역할 및 권한 할당은 다중 테넌트 시스템의 공급업체가 아니라 테넌트 또는 고객이 관리합니다.

자세한 내용은 애플리케이션 역할을 참조하세요.

테넌트 ID 및 역할 정보를 토큰에 추가

사용자가 특정 테넌트의 데이터를 사용할 수 있는지 여부를 결정하는 것을 포함하여 권한 부여 요청을 수행해야 하는 솔루션의 부분을 고려합니다.

일반적으로 ID 시스템에서 테넌트 식별자 클레임을 토큰에 포함합니다. 이 방법을 사용하면 애플리케이션에서 클레임을 검사하고 사용자가 액세스할 수 있는 테넌트에서 작업하고 있는지 확인할 수 있습니다. 역할 기반 보안 모델을 사용하는 경우 사용자가 테넌트 내에서 갖는 역할에 대한 정보를 사용하여 토큰을 확장하도록 선택할 수 있습니다.

그러나 단일 사용자가 여러 테넌트에 액세스할 수 있는 경우 사용자가 로그인 프로세스 중에 사용할 테넌트를 알리는 방법이 필요할 수 있습니다. 활성 테넌트가 선택되면 IdP에서 해당 테넌트에 대한 올바른 테넌트 식별자 클레임 및 역할을 발급하는 토큰 내에 포함할 수 있습니다. 사용자가 새 토큰을 발급해야 하는 테넌트 간에 전환할 수 있는 방법도 고려해야 합니다.

애플리케이션 기반 권한 부여

다른 방법으로 테넌트 식별자 및 역할에 구애받지 않는 ID 시스템을 만듭니다. 사용자는 자격 증명 또는 페더레이션 관계를 사용하여 식별되며, 토큰에는 테넌트 식별자 클레임이 포함되지 않습니다. 별도의 목록 또는 데이터베이스에는 각 테넌트에 대한 액세스 권한이 부여된 사용자가 포함됩니다. 그런 다음, 애플리케이션 계층에서 해당 목록을 조회하여 지정된 사용자가 특정 테넌트에 대한 데이터에 액세스할 수 있는지 여부를 확인할 수 있습니다.

Microsoft Entra ID 또는 Azure AD B2C 사용

Microsoft는 사용자 고유의 다중 테넌트 솔루션 내에서 사용할 수 있는 관리 ID 플랫폼인 Microsoft Entra ID 및 Azure AD B2C를 제공합니다.

다중 테넌트 솔루션은 대부분 SaaS(Software as a Service)입니다. Microsoft Entra ID 또는 Azure AD B2C를 사용할지 여부는 테넌트 또는 고객 기반을 정의하는 방법에 따라 부분적으로 달라집니다.

자세한 내용은 다중 테넌트 아키텍처에서 Azure Active Directory B2C를 사용하기 위한 고려 사항을 참조 하세요.

피해야 할 안티패턴

사용자 고유의 ID 시스템 구축 또는 실행

최신 ID 플랫폼을 구축하는 것은 복잡합니다. 지원할 다양한 프로토콜과 표준이 있으며, 프로토콜을 잘못 구현하고 보안 취약성을 노출하기 쉽습니다. 표준 및 프로토콜은 변경되며, 공격을 완화하고 최신 보안 기능을 지원하기 위해 ID 시스템을 지속적으로 업데이트해야 합니다. 가동 중지 시간이 솔루션의 나머지 부분에 심각한 결과를 초래할 수 있으므로 ID 시스템의 복원력을 보장하는 것도 중요합니다. 또한 대부분의 경우 ID 공급자를 구현해도 이점이 비즈니스에 추가되지 않으며 다중 테넌트 서비스를 구현하는 데 필요한 부분일 뿐입니다. 대신 전문가가 구축하고, 운영하고, 보호하는 특수 ID 시스템을 사용하는 것이 좋습니다.

사용자 고유의 ID 시스템을 실행하는 경우 암호 해시 또는 다른 형태의 자격 증명을 저장해야 하며, 이는 공격자의 유혹적인 대상이 됩니다. 공격자가 사용할 수 있는 계산 능력으로 인해 이러한 형태의 자격 증명을 손상시킬 수 있으므로 암호 해싱 및 솔팅도 보호하는 데 충분하지 않은 경우가 많습니다.

ID 시스템을 실행하는 경우 MFA 또는 OTP(일회성 암호) 코드도 생성하고 배포해야 합니다. 이러한 요구 사항은 SMS 또는 이메일을 사용하여 이러한 코드를 배포하는 메커니즘이 필요하다는 것을 의미합니다. 또한 대상 공격과 무차별 암호 대입 공격을 모두 탐지하고, 로그인 시도를 제한하고, 감사하는 등의 작업을 수행해야 합니다.

사용자 고유의 ID 시스템을 구축하거나 실행하는 대신 기존 서비스 또는 구성 요소를 사용하는 것이 좋습니다. 예를 들어 관리 ID 플랫폼인 Microsoft Entra ID 또는 Azure AD B2C를 사용하는 것이 좋습니다. 관리 ID 플랫폼 공급업체는 플랫폼에 대한 인프라를 운영하고 일반적으로 현재 ID 및 인증 표준을 지원해야 합니다.

테넌트의 요구 사항을 고려하지 못함

테넌트에는 사용하는 솔루션에 대한 ID를 관리하는 방법에 대해 강한 의견이 있는 경우가 많습니다. 예를 들어 대부분의 엔터프라이즈 고객에게는 Single Sign-On 환경을 사용하도록 설정하고 여러 자격 증명 세트를 관리하지 않기 위해 자체 ID 공급자와의 페더레이션이 필요합니다. 다른 테넌트에는 다단계 인증 또는 로그인 프로세스에 대한 다른 형태의 보호가 필요할 수 있습니다. 이러한 요구 사항에 맞게 설계하지 않은 경우 나중에 개조하기가 어려울 수 있습니다.

테넌트의 ID 요구 사항은 ID 시스템 설계를 완료하기 전에 이해해야 합니다. 다중 테넌트 솔루션의 ID에 대한 아키텍처 고려 사항을 검토하여 자주 나타나는 몇 가지 특정 요구 사항을 이해합니다.

사용자 및 테넌트 결합

솔루션에서 사용자와 테넌트를 정의하는 방법을 명확하게 고려해야 합니다. 대부분의 경우 관계는 복잡할 수 있습니다. 예를 들어 테넌트는 여러 사용자를 포함할 수 있고 단일 사용자가 여러 테넌트에 조인할 수 있습니다.

애플리케이션 및 요청 내에서 테넌트 컨텍스트를 추적하는 명확한 프로세스가 있어야 합니다. 경우에 따라 이 프로세스에서는 테넌트 식별자를 모든 액세스 토큰에 포함하고 각 요청에서 테넌트 식별자의 유효성을 검사해야 할 수 있습니다. 다른 경우에서는 테넌트 권한 부여 정보를 사용자 ID와 별도로 저장하고, 더 복잡한 권한 부여 시스템을 사용하여 특정 테넌트에 대해 특정 작업을 수행할 수 있는 특정 사용자를 관리합니다.

다중 테넌트 솔루션 내에는 항상 사용자 ID의 테넌트 컨텍스트가 있으므로 사용자 또는 토큰의 테넌트 컨텍스트 추적은 모든 테넌트 모델에 적용할 수 있습니다. 단일 테넌트에 대한 독립적인 스탬프를 배포할 때 테넌트 컨텍스트를 추적하는 것이 좋습니다. 그러면 나중에 다른 형태의 다중 테넌트에 대한 코드베이스를 사용할 수 있습니다.

역할 및 리소스 권한 부여 결합

솔루션에 적합한 권한 부여 모델을 선택해야 합니다. 역할 기반 보안 접근 방식은 구현하기가 간단할 수 있지만 리소스 기반 권한 부여는 더 세분화된 제어를 제공합니다. 테넌트의 요구 사항을 고려하고, 테넌트에서 솔루션의 다른 부분이 아닌 특정 부분에 액세스하도록 일부 사용자에게 권한을 부여해야 하는지 여부를 고려합니다.

감사 로그를 작성하지 못함

감사 로그는 환경을 이해하고 사용자가 시스템을 구현하는 방법을 이해하는 데 중요한 도구입니다. 모든 ID 관련 이벤트를 감사하면 ID 시스템에서 공격을 받고 있는지 여부를 확인하고 시스템이 사용되고 있는 방식을 검토할 수 있습니다. 감사 로그를 ID 시스템 내에 작성하고 저장해야 합니다. 테넌트에서 검토할 수 있도록 솔루션의 ID 감사 로그를 제공해야 하는지 여부를 고려합니다.

참가자

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

주요 작성자:

기타 기여자:

다음 단계

다중 테넌트 솔루션의 ID에 대한 아키텍처 고려 사항을 검토합니다.