다중 테넌시란 무엇인가？
소프트웨어 다중 테넌시는 소프트웨어 아키텍처 로, 단일 인스턴스 가 서버에서 실행되고 여러 테넌트를 서비스합니다. 이렇게 설계된 시스템은 “공유”된 것이며, “전용” 또는 “격리”된 것이 아닙니다.
테넌트는 소프트웨어 인스턴스에 특정 권한으로 공통 접근을 공유하는 사용자 그룹입니다.
다중 테넌트 아키텍처는 서비스 제공자가 여러 고객에게 표준화된 서비스를 제공할 때 자주 선호됩니다. 이러한 서비스는 일반적으로 맞춤화가 최소화되어 있으며, 모든 고객은 동일한 애플리케이션 인스턴스를 공유합니다. 애플리케이션이 업데이트되면 모든 고객에게 동시에 적용됩니다.
예를 들어, CRM(고객 관계 관리) 시스템은 종종 다중 테넌트 아키텍처를 사용하여 모든 고객에게 동일한 서비스를 제공합니다.
다중 테넌시의 핵심 원칙은 “공유”입니다. 이것은 솔루션의 모든 부분이 공유된다는 것을 의미하지 않으며, 적어도 일부 구성 요소가 여러 테넌트 간에 재사용된다는 것을 의미합니다. 이 개념을 잘 이해한다면 고객의 요구를 더 잘 해결할 수 있습니다.
다중 테넌트 제품의 사용 사례는 무엇인가요?
다중 테넌트 앱은 생산성 도구, 협업 소프트웨어 등과 같은 소프트웨어 서비스(SaaS) 제품에서 일반적으로 사용됩니다. 이 구성에서 각 “테넌트”는 일반적으로 다수의 사용자(주로 직원)가 있는 비즈니스 고객을 나타냅니다. 제품에 따라 테넌트를 워크스페이스 또는 프로젝트라고 부를 수 있습니다. 하나의 비즈니스는 여러 부서나 조직을 나타내기 위해 여러 테넌트를 가질 수 있습니다.
더 복잡한 경우, SaaS를 넘어선 B2B 애플리케이션에서는 다중 테넌트 앱이 다양한 팀, 비즈니스 클라이언트, 파트너 회사가 서비스를 이용할 수 있는 공유 플랫폼을 제공합니다.
SaaS 제품에서 다중 테넌시를 사용해야 하는 이유
다중 테넌시로 확장하기
기업 비즈니스에서는 다중 테넌시가 가용성, 리소스 관리, 비용 관리 및 데이터 보안에 대한 요구를 효과적으로 충족할 수 있는 핵심입니다. 기술적인 측면에서 다중 테넌트 접근법을 채택하면 개발 프로세스가 간소화되고 기술적 어려움이 최소화되며 원활한 확장이 촉진됩니다.
통일된 경험 만들기
SaaS 제품의 뿌리를 살펴보면, 이는 다양한 아파트가 있는 건물과 유사합니다. 모든 테넌트는 물, 전기 및 가스와 같은 공통 유틸리티를 공유하지만, 자신의 공간과 자원을 관리하는 데 독립적인 통제를 유지합니다. 이 접근 방식은 재산 관리가 간소화됩니다.
테넌트 격리를 통한 보안 보장
다중 테넌시 아키텍처에서 “테넌트”라는 용어는 공유 인스턴스 내에서 각 테넌트의 리소스와 데이터를 분리하고 보호하기 위해 도입됩니다. 이를 통해 테넌트가 동일한 기본 리소스를 활용하더라도 각 테넌트의 데이터와 작업이 독립적이고 안전하게 유지됩니다.
다중 테넌시 아키텍처에서 테넌트 격리를 어떻게 달성할 수 있나요?
다중 테넌트 애플리케이션을 논의할 때는 항상 테넌트 격리를 달성해야 합니다. 이는 다른 테넌트의 데이터와 리소스를 공유 시스템(예: 클라우드 인프라스트럭처 또는 다중 테넌트 애플리케이션) 내에서 분리하고 안전하게 유지한다는 것을 의미합니다. 이를 통해 다른 테넌트의 리소스에 대한 무단 접근을 방지할 수 있습니다.
설명이 추상적으로 보일 수 있지만, 예제와 핵심 세부 사항을 사용하여 격리 사고방식과 테넌트 격리를 달성하기 위한 모범 사례를 더욱 설명하겠습니다.
테넌트 격리는 다중 테넌시의 “공유” 사고방식에 반하지 않습니다
그 이유는 테넌트 격리가 반드시 인프라 리소스 수준의 구성이 아니기 때문입니다. 다중 테넌시와 격리의 영역에서는 일부가 격리를 실제 인프라 리소스들 간의 엄격한 분할로 봅니다. 이것은 일반적으로 각 테넌트가 별도의 데이터베이스, 컴퓨팅 인스턴스, 계정 또는 프라이빗 클라우드를 갖는 모델로 이어집니다. 공유 리소스 시나리오에서는 다중 테넌트 앱과 같은 논리적 구성을 통해 격리를 달성할 수 있습니다.
아키텍처 설계에서는 다양한 수준의 테넌트 간 리소스 격리를 달성할 수 있습니다:
일반적으로 테넌트 간에 공유되는 리소스가 많을수록 시스템 반복과 유지보수의 비용이 낮아집니다. 반대로, 공유되는 리소스가 적을수록 비용이 높아집니다.
테넌트 격리는 리소스 접근을 제한하기 위해 “테넌트” 컨텍스트 사용에만 초점을 맞춥니다. 현재 테넌트의 컨텍스트를 평가하고 해당 테넌트가 접근할 수 있는 리소스를 결정하기 위해 그 컨텍스트를 활용합니다.
인증 (Authentication)과 권한 부여 (Authorization)는 “격리”가 아닙니다
SaaS 환경에 대한 접근을 통제하기 위해 인증과 권한 부여를 사용하는 것은 중요하지만, 이것만으로는 완전한 격리를 보장할 수 없습니다. 이 메커니즘들은 보안의 일부 퍼즐일 뿐입니다.
사람들은 종종 일반적인 권한 부여 솔루션과 역할 기반 접근 제어를 사용하여 테넌트 격리를 달성할 수 있냐는 질문을 던집니다.
다중 테넌트 앱을 구축할 수 있지만 테넌트 격리 전략을 최고의 관행으로 채택했다고 할 수는 없습니다. 우리는 일반적으로 이 방법을 추천하지 않습니다. 왜냐하면 테넌트 격리는 인증 및 권한 부여와는 별개이기 때문입니다.
예를 들어, SaaS 시스템에 대한 인증 및 권한 부여를 설정했다고 가정해 보세요. 사용자가 로그인하면 애플리케이션에서 무엇을 할 수 있는지 결정하는 역할 정보가 포함된 토큰을 받습니다. 이 접근 방식은 보안을 강화하지만 격리를 보장하지 않습니다.
테넌트 격리를 달성하기 위해 SaaS 제품 테넌트를 나타내는 컨텍스트로 “조직” 사용하기
단순히 인증과 권한 부여에만 의존하면 적절한 역할을 가진 사용자가 다른 테넌트의 리소스에 접근하는 것을 막을 수 없습니다. 그래서 우리는 리소스 접근을 제한하기 위한 “테넌트” 컨텍스트(예: 테넌트 ID)를 통합해야 합니다.
이것이 테넌트 격리가 도입되는 이유입니다. 테넌트별 식별자를 사용하여 경계를 설정하고, 이 벽, 문, 자물쇠와 같은 경계를 설정하여 테넌트 간 명확한 구분을 보장합니다.
다중 테넌트 앱에서 신원은 어떻게 관리되나요?
테넌트 격리에 대해 논의했지만, 신원에 대해서는 어떨까요? 당신의 신원들이 “격리”되어야 할지 여부를 어떻게 결정하나요?
“신원 격리”라는 개념에 대한 혼란이 자주 있습니다. 이는 일반적인 사람들의 이해에서 한 현실 세계의 사용자가 두 개의 신원을 가지고 있는 상황을 가리킬 수 있습니다.
- 두 신원 모두 단일 신원 시스템 내에 존재할 수 있습니다. 예를 들어, Sarah는 개인 이메일과 단일 로그인 (SSO)으로 연결된 회사 이메일을 등록할 수 있습니다.
- 사용자가 완전히 별개인 제품을 나타내는 별도 신원 시스템 내에서 두 개의 서로 다른 신원을 유지합니다.
때때로 이러한 시나리오를 “신원 격리”라고 부르지만, 이 용어는 의사결정에 도움이 되지 않을 수 있습니다.
“신원 격리”가 필요한지 여부를 묻는 대신, 비즈니스나 제품의 일부 섹션에서 별도의 신원 시스템이 필요한지 여부를 고려하세요. 이것이 시스템 설계를 안내할 것입니다. 대부분의 경우 다중 테넌트 앱에서는 신원이 공유되는 반면 각 테넌트의 리소스는 별도로 유지됩니다.
다중 테넌트 앱에서는 테넌트 관련 리소스 및 데이터와 다르게 신원은 테넌트 간에 공유됩니다. 이는 빌딩 관리자가 되는 것과 같으며, 테넌트의 이름 리스트를 두 개 유지하고 싶지 않을 것입니다.
테넌트 격리를 목표로 할 때 “조직”이라는 용어가 자주 등장하며, 이는 다중 테넌트 앱을 구축하기 위한 가장 좋은 방법입니다.
많은 CIAM(고객 신원 관리) 또는 인증 서비스에서 “조직”을 사용함으로써 다중 테넌트 앱에서 통합된 신원 시스템을 유지하면서도 테넌트 격리를 달성할 수 있습니다.
더 나은 접근 제어를 위한 적절한 권한 모델을 어떻게 선택하나요?
올바른 권한 모델을 선택할 때 다음 질문을 고려하세요:
- B2C, B2B 또는 두 유형의 제품을 결합하여 개발하고 있나요?
- 앱이 다중 테넌트 아키텍처를 가지고 있나요?
- 비즈니스 유닛에 의해 결정된 앱에 특정 수준의 격리 필요성이 있나요?
- 조직의 컨텍스트 내에서 정의해야 할 권한과 역할은 무엇이며, 그렇지 않은 것은 무엇인가요?