다중 테넌트 인증 및 인가 설정에 대한 궁극적인 가이드

다중 테넌트 앱 구축은 고려해야 할 여러 측면이 있어 도전적일 수 있습니다. 이 기사는 다중 테넌트와 조직 관행에 대한 이해를 돕기 위해 이전 블로그 게시물들을 모았습니다. 빠르게 시작하고 시간을 절약하고 싶다면 이 기사를 참고하세요. 필요한 모든 것이 포함되어 있습니다!

일반적인 지침은 다음 단계에 설명되어 있습니다:

1. 다중 테넌트 아키텍처 이해하기
2. 당신의 다중 테넌트 앱의 사용 사례 매핑하기
3. 테넌트 격리 달성하기
4. 정체성을 어떻게 관리할 것인지 정의하기
5. 적절한 인가 모델 선택하기

다중 테넌트 아키텍처란?#

소프트웨어 다중 테넌시는 서버에서 단일 소프트웨어 인스턴스가 실행되어 여러 테넌트를 제공하는 소프트웨어 아키텍처의 한 유형입니다. 이렇게 설계된 시스템은 "전용"이나 "격리"된 것이 아닌 "공유"됩니다.

테넌트는 소프트웨어 인스턴스에 특정 권한으로 공통 액세스를 공유하는 사용자 그룹입니다.

다중 테넌시의 핵심 사고방식 중 하나는 "공유"입니다. 다중 테넌시의 광범위한 정의에서는 다중 테넌트 애플리케이션이란 것이 솔루션의 모든 구성 요소가 공유된다는 것을 의미하지 않습니다. 오히려 솔루션의 적어도 일부 구성 요소가 여러 테넌트에 걸쳐 재사용됩니다. 이 용어를 넓게 이해하면 고객의 필요를 더 잘 공감할 수 있으며, 그들이 어떤 요구 측면에서 오는지 이해할 수 있습니다.

다중 테넌트 아키텍처를 이해하면, 다음 단계는 특정 제품 및 비즈니스 요구에 초점을 맞추어 실제 시나리오에 앱을 적용하는 것입니다.

다중 테넌트 애플리케이션의 사용 사례는 무엇인가요?#

SaaS에서의 다중 테넌트#

다중 테넌트 앱은 주로 비즈니스 대 비즈니스(B2B) 솔루션, 생산성 도구, 협업 소프트웨어 및 기타 소프트웨어-as-a-service(SaaS) 제품에서 사용됩니다. 이 경우 "테넌트"는 일반적으로 여러 사용자가 있는(직원들) 비즈니스 고객을 나타냅니다. 게다가, 비즈니스 고객은 여러 조직이나 사업 부서를 나타내기 위해 여러 테넌트를 가질 수도 있습니다.

일반적인 B2B 사용 사례에서의 다중 테넌트#

B2B 애플리케이션은 SaaS 제품을 넘어 다중 테넌트 앱을 종종 포함합니다. B2B 문맥에서 이러한 앱은 여러 팀, 비즈니스 고객, 파트너 회사가 당신의 애플리케이션에 접근하기 위한 공통 플랫폼 역할을 합니다.

예를 들면, 차량 공유 회사가 B2C 및 B2B 앱 모두를 제공한다고 가정해봅시다. B2B 앱은 여러 비즈니스 고객을 서비스하며, 다중 테넌트 아키텍처를 채택하여 직원 및 자원 관리를 돕습니다. 예를 들어, 회사가 통합 사용자 ID 시스템을 유지하려면 다음과 같은 방식으로 아키텍처를 설계할 수 있습니다:

Sarah는 개인과 비즈니스 ID를 모두 가지고 있습니다. 그녀는 승객으로 차량 공유 서비스를 이용하고 있으며, 여가 시간에 운전사로 일합니다. 그녀의 직업적 역할에서 그녀는 비즈니스를 관리하며, 이 비즈니스 ID를 통해 비즈니스 1의 파트너로 활동합니다.

SaaS 제품에 다중 테넌시를 도입해야 하는 이유#

다중 테넌시로 확장하기#

기업 비즈니스에서는 다중 테넌시가 가용성, 리소스 관리, 비용 관리 및 데이터 보안을 효과적으로 충족하는 열쇠입니다. 기술적 관점에서, 다중 테넌트 접근 방식은 개발 프로세스를 간소화하고 기술적 도전을 최소화하며 원활한 확장을 촉진합니다.

통합된 경험 창출#

SaaS 제품의 근본을 확인해보면, 그것은 다양한 아파트를 가진 건물을 연상케 합니다. 모든 테넌트가 물, 전기, 가스와 같은 공공 유틸리티를 공유하지만, 각자 자신의 공간과 자원을 관리하는 독립적 권한을 유지합니다. 이 접근 방식은 부동산 관리의 복잡성을 줄입니다.

테넌트 격리를 통해 보안 보장#

다중 테넌시 아키텍처에서 "테넌트"라는 용어가 도입되어 공통 인스턴스 내에서 서로 다른 테넌트의 자원과 데이터를 분리하고 보안하기 위한 경계를 만듭니다. 이를 통해 각 테넌트의 데이터 및 운영은 동일한 기본 리소스를 사용하는 경우에도 독립적이고 안전하게 유지됩니다.

왜 테넌트 격리를 달성해야 하는가?#

다중 테넌트 애플리케이션을 논의할 때, 테넌트 격리를 항상 달성해야 합니다. 이는 서로 다른 테넌트의 데이터를 분리하고 보안을 유지하기 위해 공유 시스템(예를 들어, 클라우드 인프라나 다중 테넌트 애플리케이션) 내에서 데이터와 자원을 분리합니다. 이는 다른 테넌트의 자원에 대한 비인가된 접근 시도를 방지합니다.

설명이 추상적으로 보일 수 있지만, 격리 사고방식과 테넌트 격리를 달성하기 위한 모범 사례를 더 설명하기 위해 예제와 주요 세부 사항을 사용할 것입니다.

테넌트 격리는 다중 테넌시의 "공유" 사고방식에 반대되지 않습니다#

그것은 테넌트 격리가 반드시 인프라 자원 수준의 구조가 아니라는 것입니다. 다중 테넌시와 격리 영역에서, 일부는 격리를 실제 인프라 자원 간의 엄격한 분할로 봅니다. 이는 일반적으로 각 테넌트가 별도의 데이터베이스, 컴퓨팅 인스턴스, 계정 또는 프라이빗 클라우드를 가지는 모델로 이어집니다. 공유 자원 시나리오, 즉 다중 테넌트 앱과 같은,에서 격리를 달성하기 위한 방법은 논리적 구조일 수 있습니다.

테넌트 격리는 전적으로 "테넌트" 문맥을 사용하여 자원에 접근을 제한하는 것에 집중합니다. 현재 테넌트의 문맥을 평가하고 그 문맥을 사용하여 어떤 자원이 해당 테넌트에 접근 가능한지를 결정합니다.

인증과 인가는 "격리"와 동일하지 않습니다#

SaaS 환경에의 접근을 제어하기 위해 인증과 인가를 사용하는 것은 중요하지만, 완전한 격리를 보장할 수 없습니다. 이 메커니즘은 보안 퍼즐의 일부일 뿐입니다.

사람들은 종종 이렇게 묻습니다: 일반적인 인가 솔루션과 역할 기반 접근 제어를 사용하여 테넌트 격리를 달성할 수 있나요?

이것은 다중 테넌트 앱을 구축할 수는 있지만, 테넌트 격리 전략을 달성하고 모범 사례로 사용했다고 말할 수 없다는 것입니다. 일반적으로 우리는 이렇게 권장하지 않습니다.

예를 들어, 당신의 SaaS 시스템에 인증과 인가를 설정했다고 가정해봅시다. 사용자가 로그인하면 그들은 그들의 역할에 대한 정보를 포함한 토큰을 받으며, 애플리케이션에서 할 수 있는 작업을 지시합니다. 이 접근 방식은 보안을 강화하지만, 격리를 보장하지는 않습니다.

SaaS 제품 테넌트를 나타내기 위해 "조직" 사용하기, 테넌트 격리를 달성하기 위해#

인증과 인가에만 의존하면 올바른 역할을 가진 사용자가 다른 테넌트의 자원에 접근하는 것을 막을 수 없습니다. 따라서 우리는 테넌트 식별자와 같은 "테넌트" 문맥을 포함하여 자원 접근을 제한할 필요가 있습니다.

이것이 테넌트 격리가 발휘되는 곳입니다. 테넌트별 식별자를 사용하여 벽, 문, 자물쇠와 같은 경계를 설정하여 테넌트 간의 명확한 분리를 보장합니다.

다중 테넌트 앱에서의 정체성 관리#

테넌트 격리에 대해 논의했지만, 정체성은 어떨까요? 당신의 정체성이 "격리"되어야 하는지를 어떻게 결정하나요?

"정체성 격리"라는 개념 주위를 자주 혼동이 있습니다. 일반적인 이해에서 한 명의 실제 사용자가 두 가지 정체성을 가지는 상황을 지칭할 수 있습니다.

1. 두 정체성이 단일 정체성 시스템 내에 존재할 수 있습니다. 예를 들어, Sarah는 개인 이메일과 함께 SSO(싱글 사인 온)를 통해 연결된 회사 이메일을 가질 수 있습니다.
2. 사용자는 완전히 별개인 제품을 나타내는 별도의 정체성 시스템 내에 두 가지 고유한 정체성을 유지합니다.

때때로 이러한 시나리오는 "정체성 격리"라고 불리지만, 이 라벨은 결정을 내리는데 도움이 되지 않을 수 있습니다.

"정체성 격리가" 필요한 지를 결정하기보다는

이 답변이 당신의 시스템 설계를 안내할 수 있습니다. 다중 테넌트 앱과 관련해서는

다중 테넌트 애플리케이션에서, 테넌트별 자원과 데이터와 달리 정체성은 여러 테넌트에 걸쳐 공유됩니다. 자신을 건물 관리자로 상상해 보세요; 테넌트의 정체성을 관리하기 위해 두 개의 별도 이름표를 유지하고 싶지는 않을 것입니다.

테넌트 격리를 목표로 할 때, "조직"이라는 용어가 자주 강조된 것을 보았을 수 있으며, 이는 다중 테넌트 애플리케이션을 구축하기 위한 모범 사례로 간주됩니다.

"조직"의 개념을 사용함으로써, 당신의 다중 테넌트 애플리케이션에서 테넌트 격리를 달성하면서 통합된 정체성 시스템을 유지할 수 있습니다.

적절한 인가 모델을 선택하고 설계하는 방법#

올바른 인가 모델을 선택할 때는 다음 질문을 고려하세요:

1. B2C, B2B, 또는 두 가지 제품 유형의 조합을 개발하고 있나요?
2. 앱에 다중 테넌트 아키텍처가 있나요?
3. 비즈니스 단위에 의해 결정된 특정 격리 수준이 필요하나요?
4. 조직의 문맥에서 어떤 권한과 역할을 정의해야 하는지, 그리고 그렇지 않은 것은 무엇인지?

Logto에는 어떤 다른 인가 모델들이 있는가?#

역할 기반 접근 제어#

RBAC(역할 기반 접근 제어)는 사용자의 역할에 기반하여 권한을 부여하여 자원 접근을 효과적으로 관리하는 방법입니다.

이 일반적인 기술은 접근 제어의 기본이며 Logto의 인가 기능의 주요 구성 요소입니다. 포괄적인 정체성 관리 플랫폼인 Logto는 다양한 제품 아키텍처를 위한 맞춤 솔루션을 개발자와 기업에 제공합니다.

API 역할 기반 접근 제어#

특정 조직에 한정되지 않고 맥락 제한이 필요 없는 일반 API 자원을 보호하기 위해 API RBAC 기능이 이상적입니다.

API를 등록하고 각 자원에 권한을 할당하세요. 그런 다음, 역할과 사용자 간의 관계를 통해 접근을 제어하세요.

여기서 API 자원, 역할, 권한은 통합된 정체성 시스템 하에 "민주화"됩니다. 위계가 덜하고 매우 깊은 수준의 격리가 필요 없는 B2C 제품에서 매우 흔합니다.

조직 역할 기반 접근 제어#

B2B 및 다중 테넌트 환경에서는 테넌트 격리가 필요합니다. 이를 위해 조직은 격리를 위한 문맥으로 사용되며, 이는 사용자가 특정 조직에 속할 때만 RBAC가 효과적임을 뜻합니다.

조직 RBAC는 API 수준보다 조직 수준에서 접근을 제어하는 데 중점을 둡니다. 이는 통합된 정체성 시스템 내 조직 수준의 자가 관리를 위한 장기적인 유연성을 제공하지만, 여전히 통합된 정체성 시스템 내에 있습니다.

조직 RBAC의 주요 특징은 기본적으로 모든 조직에 걸쳐 역할과 권한이 동일하다는 것으로, Logto의 "조직 템플릿"이 개발 효율성을 향상시키는 데 매우 의미 있는 이유입니다. 이는 모든 테넌트(앱 테넌트)에 걸쳐 공통적인 인프라 구성 요소인 접근 제어 정책과 정체성이 공유되는 다중 테넌트 앱의 철학과 일치합니다.

결론#

이 기사는 다중 테넌트 앱을 준비하고 구성하는 데 필요한 모든 것을 제공합니다. 지금 Logto를 시도해보세요 그리고 조직과 함께 다중 테넌트 앱 개발을 위한 모범 사례를 적용하기 시작하세요.