다중 테넌트 앱을 구축하는 것은 고려해야 할 많은 측면이 있어 도전적일 수 있습니다. 이 기사는 다중 테넌트와 조직 관행을 이해하는 데 관한 모든 이전 블로그 게시물을 정리했습니다. 빠르게 시작하고 시간을 절약하려면 이 기사를 확인하세요. 필요한 모든 내용이 포함되어 있습니다! 일반적인 지침은 다음 단계로 개요화되어 있습니다: 1. 다중 테넌트 아키텍처 이해하기 2. 다중 테넌트 앱 사용 사례 매핑하기 3. 테넌트 격리 달성하기 4. 신원을 관리하는 방법 정의하기 5. 적절한 인증 모델 선택하기 ## 다중 테넌트 아키텍처 이해하기 소프트웨어 다중 테넌시는 [소프트웨어 아키텍처](https://en.wikipedia.org/wiki/Software_architecture)로, 하나의 [인스턴스]()의 [소프트웨어](https://en.wikipedia.org/wiki/Computer_software)가 서버에서 실행되고 여러 테넌트에 서비스를 제공합니다. 이렇게 설계된 시스템은 "공유"된 시스템입니다("전용" 또는 "격리"된 것이 아님). 테넌트는 소프트웨어 인스턴스에 특정 권한으로 공동 액세스하는 사용자 그룹을 나타냅니다. multi-tenant

다중 테넌시의 핵심 사고 방식 중 하나는 "공유"입니다. 다중 테넌시의 광범위한 정의에서 다중 테넌트 애플리케이션이라는 것은 솔루션의 **모든** 구성 요소가 공유됨을 의미하는 것은 아닙니다. 오히려, 솔루션의 적어도 **일부** 구성 요소가 여러 테넌트 간에 재사용됨을 의미합니다. 이 용어를 광범위하게 이해하는 것이 고객의 필요를 이해하고 그들이 어디에서 오는지 공감하는 데 더 도움이 될 수 있습니다. 다중 테넌트 아키텍처를 이해한 후에는, 실제 시나리오에 당신의 앱을 적용하고 특정 제품 및 비즈니스 요구에 중점을 둡니다. ## 다중 테넌트 앱 사용 사례 매핑하기 ### SaaS 다중 테넌트 앱은 일반적으로 생산성 도구, 협업 소프트웨어 및 기타 소프트웨어-서비스 (SaaS) 제품과 같은 비즈니스-비즈니스 (B2B) 솔루션에서 자리를 잡습니다. 이 맥락에서 각 "테넌트"는 일반적으로 여러 사용자를 가질 수 있는 사업 고객(그의 직원)을 나타냅니다. 또한, 사업 고객은 별개의 조직이나 비즈니스 부서를 나타내기 위해 여러 테넌트를 가질 수 있습니다. ![SaaS](https://uploads.strapi.logto.io/1/saas_product_d63c736650.webp) ### 일반 B2B 사용 사례 B2B 애플리케이션은 SaaS 제품을 넘어서는 경우가 많으며, 종종 다중 테넌트 앱을 사용하는 것이 포함됩니다. B2B 환경에서 이러한 앱은 다양한 팀, 비즈니스 고객 및 파트너 회사가 애플리케이션에 액세스할 수 있는 공통 플랫폼 역할을 합니다. 예를 들어, B2C와 B2B 앱 모두를 제공하는 차량 공유 회사를 생각해 보세요. B2B 앱은 여러 사업 고객을 제공하며, 다중 테넌트 아키텍처를 사용하여 그들의 직원과 자원을 관리하는 데 도움을 줄 수 있습니다. 예시를 들면, 회사가 단일 사용자 신원 시스템을 유지하려고 한다면, 다음과 같은 아키텍처를 설계할 수 있습니다: 사라는 개인 신원과 비즈니스 신원을 모두 가지고 있습니다. 그녀는 승객으로서 차량 공유 서비스를 사용하고 여가 시간에 운전사로도 일합니다. 그녀의 직업적 역할에서는 그녀의 비즈니스를 관리하고 이 비즈니스 신원을 사용하여 비즈니스 1의 파트너가 됩니다.

### 왜 SaaS 제품에서 다중 테넌시를 사용해야 하는가 #### 다중 테넌시로 확장하기 기업 비즈니스의 경우, 다중 테넌시는 가용성, 자원 관리, 비용 관리 및 데이터 보안을 효과적으로 충족하는 데 있어 핵심입니다. 기술적으로, 다중 테넌트 접근 방식을 채택함으로써 개발 과정을 간소화하고 기술적 과제를 최소화하며 원활한 확장을 촉진합니다. #### 통합된 경험 만들기 SaaS 제품의 기원을 조사할 때, 이는 다양한 아파트가 있는 건물을 떠올리게 합니다. 모든 테넌트는 물, 전기, 가스와 같은 공통 유틸리티를 공유하지만, 각자 자신의 공간과 자원을 관리할 때 독립적인 제어권을 유지합니다. 이 접근 방식은 재산 관리를 간소화합니다. #### 테넌트 격리를 통해 보안 보장하기 다중 테넌시 아키텍처에서는 "테넌트"라는 용어가 도입되어 공유 인스턴스 내에서 서로 다른 테넌트의 자원과 데이터를 분리하고 보안하는 경계를 생성합니다. 이는 각 테넌트의 데이터와 작업이 동일한 기반 자원을 사용하는 경우에도 분리되고 안전하게 유지되도록 보장합니다. ## 테넌트 격리 달성하기 다중 테넌트 애플리케이션을 논의할 때, **테넌트 격리**를 달성하는 것이 항상 필요합니다. 이는 공유 시스템 내에서 서로 다른 테넌트의 데이터와 자원을 분리하고 안전하게 유지하는 것을 의미합니다(예: 클라우드 인프라나 다중 테넌트 애플리케이션). 이는 다른 테넌트의 자원에 대한 무단 시도를 방지합니다. 설명이 추상적으로 보일 수 있지만, 우리는 격리 사고 방식을 추가 설명하고 최고의 실천을 통해 테넌트 격리를 달성하는 키 세부 사항을 예시와 함께 사용하겠습니다. ### 테넌트 격리는 다중 테넌시의 "공유" 사고 방식에 반하지 않는다 이는 테넌트 격리가 반드시 인프라 자원 수준의 구성 요소가 아님을 나타냅니다. 다중 테넌시와 격리의 영역에서, 일부 사람들은 격리를 실제 인프라 자원 간의 엄격한 분할로 볼 수 있습니다. 이는 일반적으로 각 테넌트가 별도의 데이터베이스, 컴퓨팅 인스턴스, 계정 또는 개인 클라우드를 가지는 모델로 이어집니다. 공유 자원 시나리오에서, 다중 테넌트 앱과 같은 방법으로 격리를 달성할 수 있는 방법은 논리적 구성 요소입니다. 테넌트 격리는 자원에 대한 접근을 제한하기 위해 "테넌트" 컨텍스트 사용에 독점적으로 중점을 둡니다. 현재 테넌트의 컨텍스트를 평가하고 해당 테넌트에 액세스 가능한 자원을 결정하기 위해 해당 컨텍스트를 사용합니다. ### 인증 및 허가는 "격리"와 같지 않음 당신의 SaaS 환경에 대한 접근을 제어하기 위해 인증과 허가를 사용하는 것은 중요하지만, 완전한 격리를 위해 충분하지 않습니다. 이러한 메커니즘은 보안 퍼즐의 한 부분일 뿐입니다. 사람들은 이러한 질문을 자주 합니다. 일반 승인 솔루션과 역할 기반 접근 제어를 사용하여 테넌트 격리를 달성할 수 있을까요? 여기 있습니다. 다중 테넌트 앱을 만들 수는 있지만 테넌트 격리 전략을 최고의 실천으로 달성하고 사용했다고 말할 수는 없습니다. 일반적으로 추천하지 않습니다. 테넌트 격리는 인증 및 허가와 별개입니다. 예를 들어, SaaS 시스템에 대한 인증과 허가를 설정했다고 가정해봅시다. 사용자가 로그인하면 역할에 대한 정보가 포함된 토큰을 받아 애플리케이션에서 수행할 수 있는 작업을 지시합니다. 이 접근 방식은 보안을 강화하지만 격리는 보장하지 않습니다. ### SaaS 제품 테넌트를 나타내기 위해 "조직" 사용하여 테넌트 격리를 달성하기 인증 및 허가만으로는 적절한 역할을 가진 사용자가 다른 테넌트의 자원에 접근하는 것을 방지할 수 없습니다. 그래서 우리는 자원에 대한 접근을 제한하기 위해 "테넌트" 컨텍스트, 예를 들어 테넌트 ID와 같이,를 통합해야 합니다. 바로 여기서 테넌트 격리가 역할을 합니다. 그것은 테넌트-특정 식별자를 사용하여 경계를 설정하며, 이는 벽, 문, 잠금을 의미하여 테넌트를 명확하게 구분합니다. ## 다중 테넌트 앱에서의 신원 우리는 테넌트 격리에 대해 논의했지만, 신원은 어떨까요? 당신의 신원이 "격리"되어야 할지 여부는 어떻게 결정합니까? "신원 격리"라는 개념에 대한 혼란이 종종 있습니다. 이는 일반적인 이해에서 한 실제 사용자에게 두 신원이 있는 상황을 나타낼 수 있습니다. 1. 두 신원은 단일 신원 시스템 내에 존재할 수 있습니다. 예를 들어, 사라는 개인 이메일과 단일 사인 온(SSO)으로 연결된 기업 이메일을 가지고 있을 수 있습니다. 2. 사용자는 완전히 독립된 제품을 나타내는 별도의 신원 시스템 내에서 두 개의 별개의 신원을 유지합니다. 이들 제품은 서로 완전히 무관합니다. 때때로, 이러한 시나리오는 "신원 격리됨"으로 불리지만, 이 레이블은 결정을 내리는 데 도움이 되지 않을 수 있습니다. 당신이 "신원 격리"가 필요한지 여부를 결정하는 것보다, 당신이나 사업의 일부분이나 제품이 별도의 신원 시스템을 유지해야 하는지를 고려하세요. 이 답변이 시스템 디자인을 안내할 수 있습니다. 다중 테넌트 앱과 관련하여 간단히 대답하자면, 대부분의 경우, 다중 테넌트 앱에서는, 신원은 공유되지만 각 테넌트의 자원은 격리됩니다. 다중 테넌트 애플리케이션에서, 테넌트-특정 자원과 데이터와 달리 신원은 여러 테넌트들 간에 공유됩니다. 관리자로서, 당신은 테넌트의 신원을 관리하기 위해 두 개의 별도의 이름 목록을 유지하고 싶지 않을 것입니다. 테넌트 격리를 목표로 할 때, "조직"이라는 용어가 다중 테넌트 애플리케이션 구축을 위한 최고의 실천으로 자주 언급된다는 것을 주목했을 것입니다. "조직"의 개념을 채택함으로써, 당신은 통합된 신원 시스템을 유지하면서 다중 테넌트 애플리케이션에서 테넌트 격리를 달성할 수 있습니다. ## 더 나은 정보 접근 제어를 위한 허가 모델 선택하기 ### 적절한 인증 모델 선택 및 설계하기 적절한 인증 모델을 선택할 때, 다음 질문을 고려하세요: 1. B2C, B2B, 혹은 둘의 조합 유형의 제품을 개발하고 있습니까? 2. 앱에 다중 테넌트 아키텍처가 있습니까? 3. 비즈니스 단위에 의해 결정된 특정 격리 수준이 앱에 필요한가요? 4. 조직의 맥락에서 정의해야 할 권한과 역할은 무엇이며, 정의하지 않아도 되는 것은 무엇인가요? ### Logto에서의 다양한 인증 모델 이해하기 #### 역할 기반 접근 제어 RBAC(역할 기반 접근 제어)는 사용자 권한 부여를 그들의 역할에 기반하여 효과적인 자원 접근 관리를 가능하게 하는 방법입니다. 이 일반적인 기술은 접근 제어의 기초를 형성하며 Logto의 승인 기능의 주요 구성 요소입니다. 포괄적인 신원 관리 플랫폼으로서, Logto는 개발자 및 사업을 위한 다양한 제품 아키텍처에 잠재적으로 적합한 솔루션을 제공합니다. #### API 역할 기반 접근 제어 특정 조직에 국한되지 않고 컨텍스트 제한이 필요하지 않은 일반 API 자원을 보호하기 위해 **_API RBAC_** 기능이 이상적입니다. 단순히 API를 등록하고 각 자원에 대한 권한을 할당합니다. 그런 다음, 역할과 사용자 간의 관계를 통해 접근을 제어합니다. 여기서 API 자원, 역할, 권한은 통합된 신원 체계 아래 "민주화"됩니다. 이는 계층 구조가 덜하고 매우 깊은 수준의 격리가 필요하지 않은 B2C 제품에서 꽤 일반적입니다. #### 조직 역할 기반 접근 제어 B2B 및 다중 테넌트 환경에서는, 테넌트 격리가 필요합니다. 이를 달성하기 위해, 조직은 격리의 맥락으로 사용되어 RBAC가 사용자가 특정 조직에 속할 때만 효과적입니다. 조직 RBAC는 API 수준이 아닌 조직 수준에서 접근을 제어하는 데 중점을 둡니다. 이는 장기적으로 조직 수준의 자가 관리에 상당한 유연성을 제공하지만 여전히 통합된 신원 체계 내에 있습니다. 조직 RBAC의 주요 특징은 역할과 권한이 기본적으로 모든 조직에서 동일하다는 점으로, 이는 로그조 "조직 템플릿"이 개발 효율성을 크게 향상시키는데 매우 의미가 있습니다. 이는 접근 제어 정책과 신원이 모든 테넌트(앱 테넌트)에서 일반적인 인프라 구성 요소인 다중 테넌트 앱의 공유 철학과 일치하며, SaaS 제품에서 일반적입니다. ## 마무리 이 기사는 다중 테넌트 앱을 준비하고 구성하기 시작하는 데 필요한 모든 정보를 제공합니다. 오늘부터 로그토를 시도하고 조직과 함께 다중 테넌트 앱 개발을 위한 최고의 실천을 적용해 보세요. 로그토 클라우드를 무료로 시도해 보세요