SaaS 애플리케이션의 보안은 설계자와 개발자 모두에게 가장 중요한 우선 순위이며, 특히 공유된 환경에서 여러 테넌트를 운영할 때는 보안 구성이 더욱 어려울 수 있습니다.
이 글에서는 AWS에서 다중 테넌트 SaaS 환경을 보호하기 위한 도전 과제와 기회 및 모범 사례에 대해 다룹니다.
SaaS 애플리케이션의 보안 고려사항
단일 테넌트 애플리케이션은 일반적으로 특정 고객을 대상으로 배포되며, 이 단일 엔터티에 대해서만 관련성을 가지고 있습니다. 이러한 환경에서는 기본적으로 다른 고객에 의한 잠재적인 접근이 발생되지 않습니다.
하지만 다중 테넌트 SaaS 애플리케이션은 단일 테넌트 SaaS 애플리케이션과 비교하여 특별한 고려 사항을 가집니다. 다중 테넌트 SaaS 애플리케이션은 주체(사용자)의 식별 및 테넌트 격리에 특별한 주의를 기울여야 합니다. 이러한 고려 사항은 모든 애플리케이션이 취해야 하는 보안 조치 항목 중 하나입니다.
다음은 사용자 식별 및 테넌트 격리와 관련된 개념과 AWS 환경에서 SaaS 제공 업체가 안전한 애플리케이션을 구축하는 데 어떻게 도움을 줄 수 있는지 검토합니다.
Identity (신원, 주체)
SaaS 애플리케이션은 일반적으로 각 주체(사용자)에 의해 액세스됩니다. 이러한 주체는 웹 애플리케이션과 같은 상호 작용형이나 API 형태의 시스템 기반일 수 있습니다. 각 주체는 고유하게 식별되며 일반적으로 주체에 대한 다른 정보(이메일 주소, 이름, 역할 및 기타 메타데이터와 같은)와연결됩니다.
신원의 고유 식별 뿐만 아니라, SaaS 애플리케이션에는 테넌트라는 또 다른 구성 요소가 있습니다. 다중 테넌트에 관한 문서에서는 테넌트를 자신이 사용하는 애플리케이션에 대해 동일하게 사용할 수 있도록 공유하는 한 명 이상의 사용자 그룹으로 정의합니다. 이러한 애플리케이션 공유는 테넌트마다 다를 수 있습니다. 1:1 매핑인 경우에도 각 개별 주체는 테넌트와 연결됩니다. 테넌트는 고유하게 식별되며 테넌트 관리자, 청구 정보 및 기타 메타 데이터에 대한 정보를 포함합니다.
SaaS 애플리케이션에서 이러한 유형의 경험을 제공하는 두 가지 핵심 기술은 IdP(ID 공급자)를 사용하고 토큰에서 ID 또는 인증을 나타내는 것입니다.
ID 공급자(IdP) 사용
과거에는 일부 웹 애플리케이션이 사용자 정보를 관계형 데이터베이스(RDBMS) 테이블에 저장하는경우가 대부분이었습니다. 주체가 성공적으로 인증되면 애플리케이션은 세션 ID를 발급하고 후속 요청의 경우 보안 주체는 세션 ID를 애플리케이션에 전달하며, 애플리케이션은 이 세션 ID를 기반으로 승인 결정을 내립니다.
하지만 복잡하고 규모가 큰 애플리케이션에서는 이러한 방식이 최적은 아닙니다. 각 요청은 일반적으로 하나 이상의 데이터베이스를 쿼리하거나 캐시 조회로 이어지는데, 사용자 또는 세션 정보를 보관하는 데이터 저장소에 병목 현상이 발생할 수 있습니다. 또한 애플리케이션과 사용자 관리 간의 긴밀한 결합성으로 인해 외부 ID 공급자(Okta와 같은)와의 연동이 어려워집니다.
SaaS 애플리케이션을 설계할 때 AWS Cognito, Auth0 또는 Okta와 같은 자격 증명 공급자의 사용을 고려해야 합니다. ID 공급자를 사용하면 외부 ID 공급자가 페더레이션을 포함하여 사용자 인증을 처리하게 되므로 ID 관리에 필요한 부담이 크게 줄어듭니다.
사용자가 ID 공급자를 통해 인증되면 ID 공급자는 표준화 된 토큰(Token)을 발급합니다. 이 토큰은 사용자 인증 방법에 관계없이 동일하기 때문에 애플리케이션은 테넌트가 사용할 수 있는 여러 가지 인증 방법에 대한 지원을 구축할 필요가 없습니다.
ID 공급자는 일반적으로 페더레이션 액세스도 지원합니다. 페더레이션 액세스는 제 3자가 ID를 유지하지만 ID 제공자가 이 제 3자와 신뢰 관계를 갖고 있음을 의미합니다. 고객이 타사에서 관리하는 ID로 로그인을 시도하면 SaaS 애플리케이션의 ID 공급자가 타사 ID 공급자와의 인증 트랜잭션을 처리합니다.
이 인증 트랜잭션은 일반적으로 SAML(Security Assertion Markup Language) 2.0과 같은 프로토콜을 사용합니다. SaaS 애플리케이션의 ID 공급자는 테넌트의 ID 공급자와의 상호 작용을 관리합니다. SaaS 애플리케이션의 ID 공급자는 SaaS 애플리케이션이 이해할 수 있는 형식으로 토큰을 발행합니다. 그림 3은 SaaS 애플리케이션이 ID 공급자를 사용하여 페더레이션을 지원하는 방법의 예를 제공합니다.
토큰(Token)을 활용한 신원 증명
신원은 일반적으로 서명된 토큰으로 표시됩니다. JWT(JSON Web Token)라고도 하는 JWS(JSON Web Signiture)는 웹 애플리케이션에서 전달자가 특정 리소스에 액세스할 수 있는 권한이 있음을 입증하는 데 사용되는 서명된 JSON 형태의 정보입니다. 이러한 JSON 정보는 ID 공급자가 서명하며 중앙 집중식 데이터베이스나 서비스에 쿼리하지 않고도 유효성을 검사할 수 있습니다.
토큰에는 ID 공급자가 발급한 클레임(Claims)이라는 여러 키-값 쌍의 값들이 포함되어 있습니다. 토큰 발급 및 만료와 관련된 여러 클레임 외에도 토큰에는 개별 신원 및 테넌트에 대한 정보가 포함될 수도 있습니다.
액세스 토큰의 클레임(Claims)
* AWS Cognito를 통해 발행된 JWT의 클레임(claims) 섹션 예시
{
"sub": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
"cognito:groups": [
"TENANT-1"
],
"token_use": "access",
"auth_time": 1562190524,
"iss": "https://cognito-idp.us-west-2.amazonaws.com/us-west-2_example",
"exp": 1562194124,
"iat": 1562190524,
"origin_jti": "bbbbbbbbb-cccc-dddd-eeee-aaaaaaaaaaaa",
"jti": "cccccccc-dddd-eeee-aaaa-bbbbbbbbbbbb",
"client_id": "12345abcde"
}
위 예시 JWT에서 신원 및 신원과 연결된 테넌트는 사용자 식별자(Sub 클레임)와 cognito:groups 클레임의 테넌트 ID의 조합으로 이 토큰에 표시됩니다. 이 예에서 SaaS 애플리케이션은 테넌트당 Cognito 그룹을 생성하여 테넌트를 나타냅니다. 다른 ID 공급자를 사용하면 액세스 토큰에 반영되는 사용자 지정 속성을 사용자에게 추가할 수 있습니다.
SaaS 애플리케이션이 요청의 일부로 JWT를 수신하면 애플리케이션은 토큰의 유효성을 검사하고 승인 결정을 내립니다. 토큰 내의 클레임은 테넌트 컨텍스트라고 알려진 것들을 설정하는데, 이것들은 SaaS 애플리케이션이 요청을 처리하는 방식에 영향을 미치게 됩니다.
JWT를 사용하면 SaaS 애플리케이션은 외부 ID 공급자나 기타 중앙 집중관리식 서비스를 자주 연결하지 않고도 요청을 처리할 수 있습니다.
테넌트 격리
테넌트의 격리는 모든 SaaS 애플리케이션의 기본 사항입니다. 각 SaaS 애플리케이션은 한 테넌트가 다른 테넌트의 리소스에 접근할 수 없도록 해야 합니다. 때문에 SaaS 애플리케이션은 한 테넌트를 다른 테넌트와 적절하게 격리하는 경계를 만들어야 합니다.
충분한 격리를 구성하는 요소를 결정하는 것은 도메인, 배포 모델 및 적용 가능한 규정 준수 프레임워크에 따라 다르고, 테넌트 간 격리하는 기술은 사용하고자 하는 격리 모델과 애플리케이션에 따라 다릅니다. 또한 애플리케이션의 배포 방법은 테넌트 격리 방법에 영향을 미칩니다.
SaaS 애플리케이션은 일반적으로 사일로(Silo), 공유(Pool), 혼합(Bridge)라는 세 가지 유형의 격리를 사용할 수 있습니다.
사일로(silo) 격리 배포 모델
사일로 배포 격리 모델은 일반적으로 고객이 테넌트 당 하나의 인프라 세트를 갖는 것입니다. 애플리케이션에 따라 테넌트 당 VPC, 테넌트 당 컨테이너 세트 또는 각 테넌트에 배포되는 기타 리소스를 의미할 수 있습니다. 이 모델에서는 테넌트 당 하나의 배포가 있지만 테넌트 간 관리를 위한 일부 공유 인프라가 있을 수 있습니다.
그림 4는 VPC 모델을 사용하여 사일로화 된 격리 배포 모델의 예시입니다.
공유(Pool) 격리 배포 모델
공유 격리 배포 모델에는 모든 테넌트들이 인프라 환경을 공유합니다. 이 안에서 테넌트 격리는 애플리케이션 수준 구성을 통해 애플리케이션에서 논리적으로 구현됩니다.
그림 5에서 모든 테넌트가 공유하는 AWS DynamoDB 테이블에서 항목을 검색하는 AWS Lambda 함수에는 AWS Security Token Service에서 발급한 임시 자격 증명이 사용합니다. 이러한 자격 증명을 통해 요청자는 요청 대상 테넌트에 속한 테이블의 항목에만 액세스할 수 있습니다. 요청자는 AWS Identity and Access Management(IAM) 역할을 맡아 이러한 자격 증명을 얻습니다. 이를 통해 SaaS 애플리케이션은 모든 인프라를 공유하는 동시에 테넌트를 서로 격리할 수 있습니다.
혼합(Bridge) 격리 배포 모델
혼합 격리 배포 모델은 사일로와 공유 모델의 요소를 일부 혼합한 모델입니다. 일부 리소스는 개별적으로 제공될 수 있고, 어떤 리소스는 공유될 수도 있습니다. 예를 들어 애플리케이션에 공유 애플리케이션 계층과 테넌트 당 Amazon Relational Database Service(RDS) 인스턴스가 있다고 가정해 보겠습니다. 애플리케이션 계층은 각 요청을 평가하고 요청을 수행한 테넌트의 데이터베이스에 연결합니다.
이 모델은 각 테넌트가 최소 응답 시간을 요구할 수 있고, 하나의 리소스 세트가 병목 현상을 일으키는 상황에서 유용합니다. 위 예시에서 애플리케이션 계층은 테넌트가 요구한 요청을 처리할 수 있지만 단일 RDS 인스턴스에서는 처리할 수 없습니다.
구현할 격리 모델에 대한 결정은 고객의 요구 사항, 규정 준수 요구 사항 또는 관련 업계의 요구 사항에 따라 달라집니다. 일부 고객은 공유 모델에 배포할 수 있지만, 대규모 고객에게는 독립적인 사일로 모델이 필요할 수 있습니다.
계층화 전략은 사용하는 격리 모델 유형에도 영향을 미칠 수 있습니다. 예를 들어 일반 고객은 공유된 인프라에 배포되고, 엔터프라이즈 고객은 사일로화 된 인프라에 배포될 수 있습니다.
또한 격리 모델은 서비스에 따라 다르게 적용됩니다.
대부분의 SaaS 애플리케이션에는 상태 정보를 저장할 위치가 필요합니다. 이는 관계형 데이터베이스나 NoSQL 데이터베이스 또는 상태를 유지하는 다른 저장소일 수 있습니다. AWS를 기반으로 구축된 SaaS 애플리케이션은 다양한 메커니즘을 사용하여 영구 스토리지 리소스에 액세스할 때 테넌트 격리를 시행합니다.
IAM은 AWS API에 대한 세분화된 액세스 제어 액세스를 제공합니다. Amazon Simple Storage Service(AWS S3) 및 DynamoDB와 같은 일부 서비스는 IAM 정책을 통해 개별 객체 또는 항목에 대한 액세스를 제어하는 기능을 제공합니다. 가능하다면 애플리케이션은 IAM의 내장 기능을 사용하여 테넌트 리소스에 대한 액세스를 제한하는 것을 권장합니다.
AWS IAM은 태그를 기반으로 리소스에 대한 액세스를 제한하는 기능도 제공합니다. 이를 속성 기반 액세스 제어(ABAC)라고 합니다. 이 기술을 사용하면 지원되는 리소스에 태그를 적용하고 적용되는 태그에 따라 액세스 제어 결정을 내릴 수 있습니다. 이는 리소스가 추가되거나 제거될 때마다 IAM 정책을 수정할 필요가 없기 때문에 역할 기반 액세스 제어(RBAC)보다 확장성이 뛰어난 액세스 제어 메커니즘입니다.
일부 관계형 데이터베이스는 테넌트 격리를 적용할 수 있는 기능을 제공합니다. 예를 들어 PostgreSQL은 행 수준 보안(RLS)이라는 기능을 제공합니다. 쿼리가 데이터베이스로 전송되는 컨텍스트에 따라 테넌트 별 항목만 결과에 반환됩니다.
마무리하며
지금까지 다중 테넌트 SaaS 애플리케이션과 관련된 보안 고려 사항에 대한 과제 및 모범 사례를 검토하고 특정 ID 공급자 및 테넌트 격리 방법을 소개하였습니다.
위 주제에 대해 더 자세히 알고 싶다면 AWS Well-Architected SaaS 렌즈 보안 원칙에서 SaaS 환경의 성능 관리에 대해 더 자세히 알아볼 수 있으며, 추가로 SaaS 애플리케이션의 성능 효율성을 설계하고 개선하는 데 도움이 되는 모범 사례와 리소스를 제공합니다.
* 출처: https://aws.amazon.com/ko/blogs/security/security-practices-in-aws-multi-tenant-saas-environments/
감사합니다 🙂