Lino의 안전한 multi-tenancy

Tenant 지원 추가

시스템이 SaaS이거나 서로 다른 고객의 데이터가 같은 애플리케이션 안에서 공존해야 하지만 컨텍스트 사이로 누출되면 안 되는 경우 Tenant 기능을 사용합니다.

lino feature tenant add

어시스턴트는 Tenants 등록, 사용자 연결, 현재 Tenant 해석, 애플리케이션 컨텍스트로의 전파 및 인증 통합을 위한 기반을 생성합니다. ITenantContext는 subdomain, host 또는 slug로 해석된 Tenant를 나타내고, IUserContext는 JWT로 인증된 사용자를 나타내며 사용자가 인증된 대상 TenantId를 포함합니다.

생성 후에는 어떤 엔티티가 실제로 Tenant에 속하고 어떤 엔티티가 global인지 검토하십시오. 이 검토는 제품 모델링의 일부입니다. multi-tenancy는 단순히 Tenants 테이블을 만드는 것이 아니라, 어떤 규칙, 화면, 권한, 데이터 및 작업이 Lino가 검증한 현재 Tenant에 의존하는지 결정하는 것입니다.

• Tenant-scoped: 주문, 고객의 제품, 회사 설정, CRM 고객 또는 특정 조직에 속한 모든 데이터.
• Global: 플랫폼의 공개 카탈로그, 플랜, 내부 운영 리소스, 관리 설정 또는 Tenant 선택 전에 사용되는 데이터.
• Hybrid: Tenant별 사용자 지정을 가진 global 데이터이며, 잘못된 중복이나 규칙 누출을 피하기 위해 명시적인 모델링이 필요합니다.

모듈식 모놀리스에서는 일반적으로 tenancy 모듈이 원본 Tenant 엔티티의 소유자입니다. catalog 또는 CRM 같은 다른 모듈은 이 엔티티에 직접 접근해서는 안 됩니다. Tenant 정보를 알아야 하는 경우, Tenant 생성 또는 업데이트 같은 integration events로 채워지는 최소 필드의 shadow entities를 유지할 수 있습니다.

Tenant context

Tenant 기능을 사용하면 Lino는 현재 Tenant 해석을 중앙화하고 그 값을 ITenantContext로 노출합니다. 이 컨텍스트는 요청의 subdomain, host 또는 slug에서 해석된 Tenant를 나타내며, Tenant를 찾은 경우 TenantId 및 slug 같은 정보를 포함합니다.

인증된 흐름에서 IUserContext는 JWT에서 사용자를 읽습니다. 그 JWT에는 사용자가 인증된 대상 TenantId도 포함됩니다. Lino는 IUserContext의 Tenant와 ITenantContext의 Tenant를 비교하여 비즈니스 규칙이 서로 다른 컨텍스트를 신뢰하지 않도록 합니다.

생성된 기능이나 나중에 추가된 기능에서는 claims를 수동으로 다시 읽거나 각 handler에서 임의의 TenantId를 받는 대신 항상 이러한 추상화를 우선하십시오. 이렇게 하면 commands, queries, 페이지 및 통합이 같은 source of truth를 사용하고 Lino가 이미 구현한 보안 메커니즘을 보존할 수 있습니다.

Background Jobs, 이벤트 소비자 및 통합에도 컨텍스트가 필요합니다. tenant-scoped 제품, 고객 또는 사용자를 처리하는 job은 처리 중인 Tenant를 명시적으로 받아야 합니다. ITenantContext와 IUserContext를 자동으로 추론할 수 있는 active HTTP request가 없기 때문입니다.

Tenant-scoped 엔티티

Tenant-scoped 엔티티는 Tenant identifier를 가지고 query filters에 참여합니다. 이렇게 하면 일반 흐름이 모든 queries에서 TenantId를 수동으로 적용해야 한다는 부담을 줄일 수 있습니다. 기능은 검증된 컨텍스트와 Lino가 생성한 filters를 사용해야 합니다.

• 특정 조직에 속하는 aggregates에는 Tenant를 포함하십시오.
• Tenant와 자주 조회되는 필드를 고려해 indexes를 구성하십시오.
• commands와 queries에서는 Tenant를 고립된 권한 원천으로 받는 대신 ITenantContext 및 IUserContext를 사용하십시오.
• imports와 jobs에서는 어떤 Tenant가 처리되는지 명시적으로 정의하십시오.

tenant-scoped 엔티티는 하나의 Tenant에 속합니다. 엔티티가 여러 Tenants에 속하는 것처럼 보이면 이를 모델링 결정으로 다루십시오. global일 수도 있고, Tenant별 복사본이 필요할 수도 있으며, 관계를 나타내는 중간 엔티티가 빠졌을 수도 있습니다. 제품, 고객 또는 사용자는 모듈마다 다른 의미를 가질 수도 있습니다. 이런 경우 원본 엔티티를 공유하는 것보다 몇 개의 필드만 가진 shadow entity가 더 정확할 수 있습니다.

참조와 ownership도 구분하십시오. catalog의 제품이 Tenant를 참조할 수는 있지만, 이것이 catalog가 Tenant lifecycle을 제어한다는 뜻은 아닙니다. tenancy 모듈은 생성, 활성화, 도메인, branding 및 격리 모드의 소유자로 남습니다. catalog는 자체 흐름을 필터링하고 검증하는 데 필요한 데이터만 유지합니다.

• Indexes: 검색, 정렬 및 Tenant별 유일성에 사용되는 필드와 TenantId를 결합하십시오.
• Commands: 엔티티가 tenant-scoped인 경우 검증된 현재 Tenant에서 작업을 적용하십시오.
• Queries: 페이지네이션, filters 및 카운터를 Lino가 검증한 같은 컨텍스트에 유지하십시오.
• Events: consumers가 producer를 부적절하게 조회하지 않고 projections를 업데이트할 수 있도록 충분한 컨텍스트를 포함하십시오.

데이터 격리

격리는 컬럼, schema 또는 별도 데이터베이스로 구현할 수 있습니다. 선택은 비용, 규모, 계약 요구사항 및 운영 역량에 따라 달라집니다.

대부분의 초기 단계 SaaS에서는 global filters와 중앙화된 컨텍스트를 갖춘 Tenant별 컬럼이 실용적인 출발점입니다. Lino는 이 기반을 돕습니다. 검토 시 tenant-scoped aggregates가 올바른 Tenant를 가지고 있고, 새 queries가 생성된 추상화로 검증된 현재 Tenant를 계속 사용하는지 확인해야 합니다.

모듈식 서비스에서 Tenant 격리와 모듈 격리는 서로 다른 관심사입니다. Catalog 모듈은 TenantId가 있는 제품 테이블을 가질 수 있고, CRM 모듈은 TenantId가 있는 고객을 가질 수 있으며, Tenancy 모듈은 원본 Tenants 등록의 소유자로 남습니다. 같은 identifier가 존재한다고 해서 모듈 간 직접 접근이 허용되는 것은 아닙니다.

Tenant별 roles 및 권한

SaaS에서는 한 사용자가 한 Tenant에서는 관리자이고 다른 Tenant에서는 운영자일 수 있습니다. Lino는 user-Tenant 연결을 다루기 위한 기반을 생성하며, 기능의 권한은 framework가 검증한 활성 컨텍스트 안에서 평가되어야 합니다.

Tenant 밖에도 관리 권한이 존재할 수 있습니다. 플랫폼 운영 화면은 system context에서만 접근 가능할 수 있고, 제품 및 고객 같은 페이지는 active Tenant를 요구할 수 있습니다. 이 분리는 작업이 global인지, 아니면 ITenantContext에서 해석된 Tenant와 IUserContext에서 인증된 사용자에 의존하는지를 명확하게 합니다.

• 권한이 조직마다 달라지는 경우 Tenant별 roles를 모델링하십시오.
• 페이지, commands 및 queries의 인가 검사에서 현재 컨텍스트를 사용하십시오.
• claims는 간결하게 유지하고, 인증된 흐름에 참여해야 하는 것만 token에 담으십시오.
• 중요 권한이 변경되면 tokens를 폐기하거나 업데이트하십시오.

JWT와 Tenant 보안

Tenant 기능이 활성화되면 Lino는 JWT를 인증된 사용자 컨텍스트의 소스로 사용합니다. IUserContext는 JWT를 데이터베이스의 복사본으로 만들지 않고, 사용자의 claims와 token의 TenantId를 읽습니다.

• issuer, audience, 서명 및 만료를 올바르게 구성해 두십시오.
• header, route 또는 화면 payload만 기반으로 한 수동 전환을 허용하는 대신 Lino가 검증한 Tenant를 사용하십시오.
• 너무 큰 claims를 피하십시오. 비대해진 tokens는 운영과 갱신을 어렵게 만듭니다.
• 흐름에 감사가 필요한 경우 사용자, Tenant 및 작업이 포함된 접근 logs를 기록하십시오.

acme.dev.localhost 및 globex.dev.localhost 같은 subdomains를 사용하는 애플리케이션에서 ITenantContext는 요청에 대해 해석된 Tenant를 나타냅니다. IUserContext는 인증된 사용자와 JWT에 존재하는 Tenant를 나타냅니다. Lino는 이 두 컨텍스트를 비교하여 한 Tenant에 대해 발급된 token이 다른 Tenant 컨텍스트에서 사용되는 것을 방지합니다.

인가도 계속 컨텍스트를 따릅니다. 예를 들어 제품 보기 권한은 그 권한이 부여되고 사용자가 인증된 Tenant 안에서 유효합니다. 새 기능을 만들 때는 느슨한 TenantId를 받아 인증된 흐름을 무시하는 지름길을 만들지 말고, 이미 사용 가능한 권한과 컨텍스트를 사용하십시오.