멀티 테넌트 애플리케이션에서의 테넌트 격리
테넌트 격리는 멀티 테넌트 애플리케이션의 핵심 개념입니다. 이 기사에서는 그것이 무엇인지 및 어떻게 달성할 수 있는지를 논의할 것입니다.
Product & Design
안녕하세요 여러분! 이 장에서는 멀티 테넌트 주제에 대한 이전 논의를 기반으로 합니다. 아직 이전 기사를 읽지 않았다면 먼저 그것들을 읽어보기를 권장합니다!
멀티 테넌트 애플리케이션을 논의할 때, 테넌트 격리에 대해 생각하는 것이 중요합니다. 이는 다른 테넌트의 데이터와 리소스를 공유 시스템(예: 클라우드 인프라 또는 멀티 테넌트 애플리케이션) 내에서 별도로 안전하게 유지하는 것을 의미합니다.
테넌트 격리의 목표는 동일한 기본 리소스를 사용하더라도 각 테넌트의 데이터와 작업이 서로 구분되고 안전하게 유지되도록 하는 것입니다.
Software as a Service (SaaS) 시나리오에서 테넌트 격리는 리소스 접근을 엄격하게 조절하는 구조를 SaaS 프레임워크 내에 생성하는 것을 포함합니다. 이는 다른 테넌트의 리소스를 무단으로 접근하려는 시도를 방지합니다.
설명이 추상적으로 보일 수 있지만, 우리는 예제와 주요 세부사항을 사용하여 격리 사고방식을 더 설명할 것입니다.
테넌트 격리는 멀티 테넌시의 "공유" 사고방식에 반하지 않습니다
이는 테넌트 격리가 반드시 인프라 리소스 수준의 구성이 아니라는 이유에서 그렇습니다. 멀티 테넌시와 격리 영역에서 어떤 사람들은 격리를 실제 인프라 리소스 사이의 엄격한 분리로 봅니다. 이는 각 테넌트가 별도의 데이터베이스, 컴퓨팅 인스턴스, 계정 또는 개인 클라우드를 갖는 모델로 보통 이어집니다. 멀티 테넌트 앱 같은 공유 리소스 시나리오에서는 격리를 달성하는 방법이 논리적 구성이 될 수 있습니다.
테넌트 격리는 리소스 접근을 제한하기 위해 오로지 “테넌트“ 컨텍스트를 사용하는 것에 초점을 맞춥니다. 이는 현재 테넌트의 콘텍스트를 평가하고 해당 테넌트에 접근할 수 있는 리소스를 결정하기 위해 그 콘텍스트를 사용합니다. 이는 해당 테넌트 내의 모든 사용자에게 이 격리를 적용합니다. 테넌트 리소스에 대한 접근 시도는 그 테넌트에 속한 리소스로만 범위가 지정되어야 합니다.
격리는 다양한 수준에서 이루어집니다
격리가 인프라 리소스 수준에 엄격하게 얽매여 있지 않고 물리적 인프라 사이의 분명한 분리가 아님을 이해할 때, 다음과 같은 결론에 도달합니다:
격리를 단순히 "예" 또는 "아니오"로 보지 말고 스펙트럼으로 생각하세요. 필요한 것에 따라 시스템 부분을 더 격리하거나 덜 격리하도록 설정할 수 있습니다.
아래 다이어그램은 이 격리의 스펙트럼을 보여줍니다.
인증과 권한 부여는 "격리"와 동일하지 않습니다
SaaS 환경에 대한 접근을 통제하기 위해 인증과 권한 부여를 사용하는 것은 중요하지만, 이는 완전한 격리를 위해 충분하지 않습니다. 이러한 메커니즘들은 보안 퍼즐의 일부일 뿐입니다.
사람들은 종종 일반적인 권한 부여 솔루션과 역할 기반 접근 제어를 사용해 테넌트 격리를 달성할 수 있는지 질문합니다. 멀티 테넌트 앱을 만들 수는 있지만 테넌트 격리 전략을 최선의 관행으로 달성하고 실행했다고 말할 수는 없습니다. 일반적으로 우리는 추천하지 않습니다.
설명을 위해 SaaS 시스템에 대한 인증과 권한 부여를 설정한 상황을 고려해 보세요. 사용자가 로그인하면 그들의 역할에 대한 정보를 담고 있는 토큰을 받으며 이는 애플리케이션에서 그들이 할 수 있는 일을 지시합니다. 이 접근 방식은 보안을 강화하지만 격리를 보장하지는 않습니다.
여기서 중요한 점은: 자원 접근을 제한하기 위한 테넌트 ID 같은 "테넌트" 컨텍스트를 도입하지 않으면, 단순히 인증과 권한 부여에 의존하는 것은 권한 있는 사용자가 다른 테넌트의 리소스를 접근하지 못하게 하지 못합니다.
이것이 테넌트 격리가 필요한 이유입니다. 이는 벽, 문, 자물쇠와 같은 경계를 설정하기 위해 테넌트 별 식별자를 사용하여 테넌트 간의 명확한 구분을 보장합니다.
멀티 테넌트 앱의 정체성
테넌트 격리를 논의했지만 그럼 정체성은 무엇일까요? 어떻게 당신의 정체성을 "격리"할 것인지 아닌지 결정할 수 있을까요?
"정체성 격리" 개념은 자주 혼란을 일으킵니다. 이는 한 명의 사용자가 일반적으로 인식하는 두 개의 정체성을 가지는 상황을 나타낼 수 있습니다.
- 두 정체성은 하나의 정체성 시스템 내에 존재할 수 있습니다. 예를 들어, Sarah는 개인 이메일과 단일 사인온(SSO)을 통해 연결된 회사 이메일을 함께 등록할 수 있습니다.
- 사용자는 별도의 정체성 시스템 내에서 두 개의 별도의 정체성을 유지하며 이는 완전히 별개의 제품을 나타냅니다. 이 제품들은 서로 전혀 관련이 없습니다.
때때로 이러한 상황들은 "정체성 격리"라고 불립니다. 그러나 이 라벨이 결정을 돕는지는 모릅니다.
"정체성 격리"가 필요한지 여부를 결정하기보다는, 당신 또는 당신의 비즈니스나 제품의 일부가 별도의 정체성 시스템을 유지할 필요가 있는지 아닌지를 고려하세요. 이 답 변이 정체성과 접근 관리(IAM) 시스템 디자인을 안내할 수 있습니다. 멀티 테넌트 앱에 대한 간단한 대답으로는,
대다수의 경우, 멀티 테넌트 앱에서는 각각의 테넌트의 리소스가 격리되는 반면, 정체성은 공유됩니다.
멀티 테넌트 애플리케이션에서, 테넌트 별 리소스 및 데이터와는 달리 정체성은 여러 테넌트 간에 공유됩니다. 자신을 건물 관리자라고 생각해보세요; 각각의 테넌트의 정체성을 관리하기 위해 두 개의 별도의 이름표를 유지하고 싶지 않을 것입니다.
테넌트 격리를 목표로 할 때, "조직"이라는 용어가 자주 강조되는 것을 보았을 것입니다. 이는 멀티 테넌트 애플리케이션 구축의 최선의 관행으로 여겨집니다.
"조직"이라는 개념을 사용하여, 멀티 테넌트 애플리케이션에서 테넌트 격리를 달성하면서 통일된 정체성 시스템을 유지할 수 있습니다. 이는 여러 "조직"이 독립적으로 공존하면서 애플리케이션 내에서 테넌트 비의존적 리소스를 공유할 수 있게 합니다. 건물에 사는 주민들처럼, 각각의 조직은 이웃에 대한 걱정 없이 애플리케이션을 활용합니다. "조직"은 벽, 복도, 문, 자물쇠의 형태로 필요한 분리를 제공합니다. 그들은 전체 건물 인프라, 내부 디자인 시스템, 다양한 유형의 유무형 요소를 공유합니다.
Logto는 11월 "조직" 기능을 소개합니다
Logto는 현재 "조직" 기능의 적극적인 개발 중이며 2023년 11월 출시를 목표로 하고 있습니다. 이 기능은 SaaS 제품 구축에 필요한 테넌트 격리 요건을 충족시키고자 만들어졌으며, 이는 업계 표준 및 최선의 관행과 일치합니다.
다음 장에서는 "조직" 기능에 대해 더 깊이 알아보고 Logto가 멀티 테넌트 애플리케이션 구축을 위한 최선의 관행 구현을 어떻게 지원하는지를 탐구할 것입니다.