테넌트 격리
고객을 멀티 테넌트 모델로 전환시킬수록 고객은 한 테넌트가 다른 테넌트의 리소스에 액세스할 가능성에 대해 더 우려하게 됩니다. SaaS 시스템에는 공유 인프라에서 실행되는 경우에도 각 테넌트의 리소스가 격리되도록 하는 명시적인 메커니즘이 포함되어 있습니다.
이를 테넌트 격리라고 합니다. 테넌트 격리의 기본 개념은 SaaS 아키텍처가 리소스에 대한 액세스를 엄격하게 제어하고 다른 테넌트의 리소스에 액세스하려는 시도를 차단하는 구성을 도입한다는 것입니다.
단, 테넌트 격리는 일반 보안 메커니즘과는 별개입니다. 시스템은 인증 및 권한 부여를 지원하지만 테넌트 사용자가 인증되었다고 해서 시스템이 격리된 것은 아닙니다. 격리는 응용 프로그램의 일부일 수 있는 기본 인증 및 권한 부여와는 별도로 적용됩니다.
이를 더 잘 이해하기 위해 자격 증명 공급자를 사용하여 SaaS 시스템에 대한 액세스를 인증했다고 가정해 보겠습니다. 이 인증 경험의 토큰에는 특정 애플리케이션 기능에 대한 사용자 액세스를 제어하는 데 사용할 수 있는 사용자 역할에 대한 정보도 포함될 수 있습니다. 이러한 구조는 보안을 제공하지만 격리는 제공하지 않습니다. 실제로 사용자는 인증을 받고 권한을 부여받은 후에도 다른 테넌트의 리소스에 계속 액세스할 수 있습니다. 인증 및 권한 부여에 관한 어떤 것도 이러한 액세스를 반드시 차단할 수는 없습니다.
테넌트 격리는 테넌트 컨텍스트를 사용하여 리소스에 대한 액세스를 제한하는 데만 중점을 둡니다. 현재 테넌트의 컨텍스트를 평가하고 해당 컨텍스트를 사용하여 해당 테넌트가 액세스할 수 있는 리소스를 결정합니다. 이 격리는 해당 테넌트 내의 모든 사용자에게 적용됩니다.
다양한 SaaS 아키텍처 패턴에서 테넌트 격리가 실현되는 방식을 살펴보면 이는 더욱 어려워집니다. 네트워크(또는 좀 더 세부적인) 정책으로 테넌트 간 액세스를 허용하지 않는 경우 전체 리소스 스택을 테넌트 전용으로 사용하여 격리를 달성할 수도 있습니다. 다른 시나리오에서는 리소스 액세스를 제어하기 위해 보다 세분화된 정책이 필요한 풀링된 리소스(Amazon DynamoDB
테넌트 리소스에 액세스하려는 모든 시도는 해당 테넌트에 속하는 리소스로만 범위를 지정해야 합니다. 특정 애플리케이션의 격리 요구 사항을 지원할 도구 및 기술 조합을 결정하는 것은 SaaS 개발자와 설계자의 임무입니다.
