AWS 멀티테넌트 SaaS 환경의 보안 사례

본 게시물은 AWS Security Blog에 게시된 Security practices in AWS multi-tenant SaaS environments” by Keith P and Andy Powell을 한국어로 번역한 글입니다.

SaaS(Software-as-a-Service) 애플리케이션에서 보안은 모든 애플리케이션 설계자와 개발자에게 가장 중요한 사항입니다. SaaS 환경에서 리소스를 여러 테넌트에게 공유하기 때문에 애플리케이션을 보호하는 것이 훨씬 어려울 수 있습니다. 자격 증명 프레임워크와 개념을 이해하는데는 시간이 걸리며, 테넌트 격리를 위해서는 다양한 도구와 서비스에 대한 깊은 이해가 필요합니다.

보안은 모든 소프트웨어 애플리케이션의 기본 요소이지만, SaaS 애플리케이션에는 특별한 사항을 고려해야 합니다. 이 글에서는 Amazon Web Services(AWS)에서 멀티 테넌트 SaaS 환경을 보호하기 위한 도전과제, 기회 및 모범 사례를 자세히 살펴봅니다.

SaaS 애플리케이션 보안 고려 사항

단일 테넌트 애플리케이션은 대개 특정 고객을 위해 배포되며, 일반적으로 단일 대상만 다룹니다. 이러한 환경에서는 보안이 중요하지만, 단일 대상만 처리하므로 다른 고객이 애플리케이션에 접근하는 것을 고려하지 않아도 됩니다. 단일 테넌트 애플리케이션에 비해 멀티테넌트 SaaS 애플리케이션에서는 특별하게 고려해야 하는 사항이 있습니다.

특히 멀티테넌트 SaaS 애플리케이션에서는 자격 증명과 테넌트 격리를 특별히 주의해야 합니다. 이것은 모든 애플리케이션에서 지켜야하는 보안 사항에 추가로 적용되는 것입니다. 이 글에서는 자격 증명과 테넌트 격리와 관련된 개념을 알아보고, AWS가 안전한 SaaS 애플리케이션을 구축하는 데 어떤 도움을 줄 수 있는지 살펴봅니다.

자격 증명

대개 사용자라고 지칭하는 개별 보안 주체는 SaaS 애플리케이션에 접근합니다. 사용자는 SaaS 애플리케이션에 대화형(예: 웹 애플리케이션 사용)으로 접근하거나 머신 기반(예: API 사용)으로 접근할 수 있습니다. 사용자는 고유하게 식별되며 보통 이메일 주소, 이름, 역할 등의 정보와 연관되어 있습니다.

SaaS 애플리케이션은 각 개별 사용자를 고유하게 식별하는 것 외에도 테넌트라는 또 다른 구조를 가지고 있습니다. paper on multi-tenancy 에서는 테넌트를 정의하고 있으며, 테넌트를 애플리케이션에서 동일한 뷰를 가지는 한 명 이상의 사용자 그룹으로 정의합니다. 뷰는 테넌트마다 다를 수 있습니다. 사용자와 테넌트의 관계가 1:1 관계이더라도 개별 사용자는 하나의 테넌트와 연결됩니다. 테넌트는 고유하게 식별되며 테넌트 관리자, 청구 정보 등의 정보를 포함합니다.

사용자는 SaaS 애플리케이션에 요청을 할 때 테넌트 정보와 자신이 가진 사용자 식별자 정보를 제공합니다. SaaS 애플리케이션은 전달받은 정보를 검증하고, 권한 부여에 대한 결정을 합니다. 잘 설계된 SaaS 애플리케이션에서는 이러한 권한 부여 작업을 중앙 집중적인 권한 부여 서비스에 의존하지 않습니다. 중앙 집중적인 권한 부여 서비스는 애플리케이션에서 단일 장애 지점이 됩니다. 만일 요청을 처리하는 데 실패하거나 요청이 너무 많으면, 애플리케이션에서는 요청을 더 이상 처리할 수 없게 됩니다.

SaaS 애플리케이션에서 이러한 유형의 경험을 제공하기 위한 두 가지 핵심 기술이 있습니다.

자격 증명 공급자(IdP) 사용
토큰에 자격 증명 또는 인증 정보 표현

자격 증명 공급자 (IdP) 사용

과거 일부 웹 애플리케이션에서는 사용자 정보를 종종 관계형 데이터베이스 테이블에 저장했습니다. 사용자가 성공적으로 인증되면 애플리케이션에서 세션 ID를 발급했습니다. 추가 요청을 하는 경우, 사용자가 세션 ID를 애플리케이션에 전달했습니다. 애플리케이션은 이 세션 ID를 기반으로 권한 부여 결정을 내렸습니다. 그림 1은 앞서 설명한 기존 애플리케이션의 인증 예시입니다.

그림 1 – 기존 애플리케이션 인증의 예

이 패턴은 규모가 큰 애플리케이션에 최적은 아닙니다. 각 요청은 일반적으로 하나 이상의 데이터베이스 쿼리 또는 캐시 조회를 발생시켜 사용자 또는 세션 정보를 가진 데이터 저장소에 병목 현상을 일으킵니다. 또한 이 패턴에서는 애플리케이션과 애플리케이션의 사용자 관리 기능이 강하게 결합되어 있기 때문에 외부 자격 증명 공급자와 연동하는 것이 어렵습니다.

SaaS 애플리케이션을 설계할 때는 Amazon Cognito, Auth0 또는 Okta와 같은 자격 증명 공급자의 사용을 고려해야 합니다. 왜냐하면 자격 증명 공급자를 사용하면 자격 증명 공급자가 외부 자격 증명 공급자와 연동을 비롯한 사용자 인증을 처리하므로 자격 증명 관리에 필요한 번거로운 작업이 줄어들기 때문입니다. 그림 2는 SaaS 공급자가 자체 자격 증명 관리 솔루션(그림 1 방식)을 사용하지 않고 자격 증명 공급자를 사용하는 예시입니다.

그림 2 – 자격 증명 공급자와 관련된 인증 흐름 예

사용자가 자격 증명 공급자를 통해 인증하면, 자격 증명 공급자는 표준화된 토큰을 발급합니다. 이 토큰은 사용자 인증 방식에 관계없이 동일하기 때문에 다양한 인증 방법을 지원하도록 애플리케이션을 구축하지 않아도 됩니다.

자격 증명 제공자는 일반적으로 페더레이션 접근도 지원합니다. 페더레이션 접근이란 서드 파티 자격 증명을 유지하지만, 자격 증명 제공자가 서드 파티 자격 증명자와 신뢰 관계를 유지하는 것을 의미합니다. 고객이 서드 파티에서 관리하는 자격 증명으로 로그인을 시도하면 SaaS 애플리케이션의 자격 증명 공급자가 서드 파티 자격 증명 공급자와의 인증 트랜잭션을 처리합니다.

인증 트랜잭션은 일반적으로 Security Assertion Markup Language(SAML) 2.0과 같은 프로토콜을 사용합니다. SaaS 애플리케이션의 자격 증명 공급자는 테넌트의 자격 증명 공급자와 상호 작용을 합니다. SaaS 애플리케이션의 자격 증명 공급자는 SaaS 애플리케이션이 이해할 수 있는 형태로 토큰을 발행합니다. 그림 3은 SaaS 애플리케이션이 자격 증명 공급자를 사용해 외부 자격 증명자와 연동하여 인증하는 예시입니다.

그림 3 — 테넌트가 제공하는 자격 증명 공급자와 관련된 인증의 예

예제는 How to set up Amazon Cognito for federated authentication using Azure AD에서 확인할 수 있습니다.

토큰으로 자격 증명 표현

자격 증명은 일반적으로 서명된 토큰으로 표시됩니다. JSON Web Tokens(JWT)이라고도 하는 JSON Web Signatures(JWS)은 웹 애플리케이션에서 전달자(bearer)가 특정 리소스에 액세스할 수 있는 권한이 있음을 나타내기 위해 사용되는 서명된 JSON 객체입니다. 이 JSON 객체는 자격 증명 공급자가 서명하며, 중앙 집중식 데이터베이스나 서비스를 조회하지 않고 검증할 수 있습니다.

토큰은 자격 증명 공급자가 발행한 클레임(claim)이라고 불리는 여러 키-값 쌍을 포함하고 있습니다. 토큰은 토큰의 발행 및 만료와 관련된 몇 가지 클레임 외에도 사용자 및 테넌트에 대한 정보를 포함할 수 있습니다.

액세스 토큰 클레임 샘플

아래 예는 Amazon Cognito에서 JWT 형식으로 발급한 일반적인 액세스 토큰 클레임 예시입니다.

{ 
    "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" 
}

토큰에서 사용자 및 테넌트는 사용자 식별자(sub 클레임)와 cognito:groups 클레임 내의 테넌트 ID의 조합으로 표현됩니다. 이 예에서 테넌트는 하나의 Cognito 그룹으로 표현됩니다. Cognito 외 다른 자격 증명 공급자에서도 액세스 토큰에 포함되는 사용자 정보에 사용자 지정 속성을 추가할 수 있습니다.

SaaS 애플리케이션이 사용자 요청과 함께 JWT를 수신하면, 애플리케이션은 이 JWT 토큰의 유효성을 검사하고 권한을 결정하기 위해 토큰 내용을 확인합니다. 토큰 내의 클레임은 테넌트 컨텍스트를 설정합니다. 환경 변수가 커맨드라인 애플리케이션에 영향을 미칠 수 있는 것처럼, 테넌트 컨텍스트는 SaaS 애플리케이션에서 요청을 처리하는 방식에 영향을 줍니다.

SaaS 애플리케이션은 JWT를 사용함으로써 외부 자격 증명 공급자나 다른 중앙 집중식 서비스를 빈번하게 참조하지 않고도 요청을 처리할 수 있습니다.

테넌트 격리

테넌트 격리는 모든 SaaS 애플리케이션의 기본입니다. SaaS 애플리케이션에서는 한 테넌트가 다른 테넌트의 리소스에 접근할 수 없도록 해야 합니다. SaaS 애플리케이션에서는 한 테넌트를 다른 테넌트와 적절히 분리하는 경계를 만들어야 합니다.

충분한 격리 수준을 결정하는 것은 도메인, 배포 모델, 규정 준수 프레임워크에 따라 달라집니다. 테넌트 격리 기술은 격리 모델과 애플리케이션에 따라 달라집니다. 이 섹션에서는 테넌트 격리 전략에 대한 개요를 소개합니다.

배포 모델은 격리에 영향을 미칩니다.

애플리케이션의 배포 방식은 테넌트 격리 방식에 영향을 미칩니다. SaaS 애플리케이션에서는 사일로, 풀, 브리지의 세 가지 유형의 격리를 채택할 수 있습니다.

사일로 배포 모델

사일로 배포 모델은 각 테넌트마다 하나의 인프라 세트를 배포하는 것을 의미합니다. 애플리케이션에 따라 사일로 배포 모델은 테넌트당 VPC를 의미할 수도 있고, 테넌트당 컨테이너 세트 또는 각 테넌트에 배포되는 기타 리소스를 의미할 수 있습니다. 이 모델에서는 테넌트 간 관리를 위한 공유 인프라가 있을 수 있습니다. 그림 4는 테넌트당 VPC 모델을 사용하는 사일로 배포의 예시입니다.

그림 4 — 테넌트당 VPC를 프로비저닝하는 사일로 배포의 예

풀 배포 모델

풀 배포 모델은 모든 테넌트가 공유하는 인프라를 사용하는 것입니다. 테넌트 격리는 애플리케이션 수준의 구성을 통해 애플리케이션 수준에서 논리적으로 구현됩니다. 테넌트별로 리소스를 분리하는 대신 애플리케이션 내에서 격리가 이뤄집니다. 그림 5는 서버리스 기술을 사용하는 풀 배포 모델의 예시입니다.

그림 5 — 서버리스 기술을 사용하는 풀 배포 모델의 예

그림 5의 AWS Lambda 함수는 모든 테넌트가 공유하는 Amazon DynamoDB 테이블에서 아이템을 검색하며, 이 Lambda 함수에 접근하기 위해서 AWS Security Token Service에서 발급한 임시 자격 증명이 필요합니다. 이러한 자격 증명을 이용하여 요청자는 연관된 테넌트에 대한 테이블 항목에만 접근할 수 있습니다. 요청자는 AWS Identity and Access Management(IAM) 역할을 통해 자격 증명을 얻습니다. 이를 통해 SaaS 애플리케이션은 기본 인프라를 공유하면서도 테넌트를 다른 테넌트와 격리할 수 있습니다. 이 패턴에 대한 자세한 내용은 아래의 서비스에 따른 격리 강화 섹션에서 확인할 수 있습니다.

브리지 배포 모델

브리지 모델은 사일로 모델과 풀 모델을 결합한 것입니다. 일부 리소스는 분리되어 있을 수 있고, 다른 리소스는 공유될 수 있습니다. 예를 들어, 애플리케이션은 모든 테넌트에게 공유되는 애플리케이션 계층 그리고 테넌트별로 분리된 Amazon Relational Database Service(RDS) 인스턴스로 구성되어 있다고 가정해 보겠습니다. 애플리케이션 계층에서는 각 요청을 평가하고, 요청을 처리하기 위해 테넌트와 관련된 데이터베이스에 접근합니다.

이 모델은 각 테넌트가 특정한 응답 시간을 요구하고 특정 자원 집합이 병목 현상을 일으킬 때 유용합니다. 위에서 가정한 RDS 예제에서 애플리케이션 계층은 테넌트의 요청을 처리할 수 있지만, 단일 RDS 인스턴스는 테넌트의 요청을 처리할 수 없었습니다.

어떤 격리 모델을 구현할지 결정하는 것은 고객의 요구 사항, 규정 준수 요구 사항 또는 업계 요구 사항에 따라 달라집니다. 일부 고객은 풀 모델로 배포할 수 있지만 큰 규모의 고객은 자체적인 사일로 배포가 필요할 수 있습니다.

티어링 전략은 격리 모델 유형에도 영향을 미칠 수 있습니다. 예를 들어 베이직 티어 고객은 공유되는 인프라에 배포되지만, 엔터프라이즈 티어 고객은 전용 인프라에 배포될 수 있습니다.

다양한 테넌트 격리 모델에 대한 자세한 내용은 tenant isolation strategies whitepaper를 참고하시길 바랍니다.

서비스에 따른 격리 강화

대부분의 SaaS 애플리케이션에서는 데이터 저장 공간이 필요합니다. 저장 공간은 관계형 데이터베이스, NoSQL 데이터베이스 또는 다른 영구 저장 매체가 될 수 있습니다. AWS에 구축된 SaaS 애플리케이션은 다양한 메커니즘을 사용하여 테넌트 격리를 적용합니다.

IAM은 AWS API에 대한 세밀한 접근 제어 기능을 제공합니다. Amazon Simple Storage Service(Amazon S3) 및 DynamoDB와 같은 일부 서비스는 IAM 정책을 통해 개별 객체 또는 개별 항목에 대한 접근 제어 기능을 제공합니다. 가능하면 애플리케이션은 IAM의 내장 기능을 사용하여 테넌트 리소스에 대한 접근을 제한해야 합니다. IAM을 사용하여 테넌트 격리를 구현하는 방법에 대한 자세한 내용은 Isolating SaaS Tenants with Dynamically Generated IAM Policies를 참고하시길 바랍니다.

AWS IAM은 태그를 기반으로 리소스에 대한 접근을 제한하는 기능도 제공합니다. 이를 attribute-based access control(ABAC) 이라고 합니다. 이 기술을 사용하면 리소스에 태그를 적용하고, 태그에 따라 접근 제어 결정을 내릴 수 있습니다. 리소스가 추가되거나 제거될 때마다 IAM 정책을 수정할 필요가 없기 때문에 role-based access control(RBAC)보다 확장성이 뛰어난 접근 제어 메커니즘입니다. 이를 SaaS 애플리케이션에 적용하는 방법에 대한 자세한 내용은 How to implement SaaS tenant isolation with ABAC and AWS IAM을 참고하시길 바랍니다.

일부 관계형 데이터베이스에서는 테넌트 격리를 강제할 수 있는 기능을 제공합니다. 예를 들어 PostgreSQL은 행 수준 보안 (RLS) 기능을 제공합니다. 데이터베이스에 질의하는 컨텍스트에 따라서 연관된 테넌트에 대한 항목만 결과로 반환됩니다. PostgreSQL의 행 수준 보안에 대한 자세한 내용은 Multi-tenant data isolation with PostgreSQL Row Level Security를 참고하시길 바랍니다.

다른 저장 매체에는 세분화된 권한 모델이 없습니다. 그러나 테넌트별로 일종의 상태 컨테이너를 제공할 수 있습니다. 예를 들어 MongoDB를 사용하는 경우, 각 테넌트에 MongoDB 사용자 및 MongoDB 데이터베이스가 할당됩니다. 사용자와 관련된 암호는 AWS Secret Manager에 저장할 수 있습니다. SaaS 애플리케이션은 테넌트의 데이터를 검색할 때 먼저 암호를 검색한 후 MongoDB에 인증합니다. 이렇게 하면 관련 자격 증명이 테넌트에 대한 데이터베이스 데이터에 접근할 수 있는 권한만 가지고 있기 때문에 테넌트 격리가 됩니다.

일반적으로 사용 중인 저장 매체가 테넌트 격리를 적용할 수 있는 자체 권한 모델을 제공한다면 이를 사용해야 하는데, 왜냐하면 애플리케이션에서 격리를 따로 구현하지 않아도 되기 때문입니다. 하지만 데이터 저장소가 이러한 수준의 격리를 제공하지 않는 경우도 있습니다. 이 상황에서는 애플리케이션 수준에서 테넌트 격리를 해야 합니다. 애플리케이션 수준의 테넌트 격리는 저장 매체가 아닌 SaaS 애플리케이션에서 한 테넌트가 다른 테넌트의 데이터에 액세스할 수 없게 하는 것을 의미합니다.

결론

이 게시물에서는 멀티 테넌트 SaaS 애플리케이션과 관련된 고유한 보안 고려 사항에 대한 도전과제, 기회 및 모범 사례를 검토하고, 특정 자격 증명에 대한 고려 사항과 테넌트 격리 방법을 설명했습니다.

위의 주제에 대해 더 자세히 알고 싶다면 AWS Well-Architected SaaS Lens Security pillar에서 SaaS 환경에서의 심층적인 성능 관리 방법과 SaaS 애플리케이션의 성능 효율성을 설계하고 개선하는 데 도움이 되는 모범 사례 및 리소스를 확인하실 수 있습니다.

AWS Well-Architected SaaS Lens로 시작하기

AWS Well-Architected SaaS Lens는 SaaS 워크로드에 중점을 두고 있으며, SaaS 워크로드 개발 및 운영에 대한 비판적 사고를 가질 수 있도록 도움을 줍니다. SaaS Lens의 각 질문에는 모범 사례 목록이 있으며, 각 모범 사례에는 이를 구현하는 데 도움이 되는 항목을 함께 나타내고 있습니다.

SaaS 렌즈는 기존 워크로드에 적용하거나 새 워크로드에 적용할 수 있습니다. 이를 사용하여 작업 중인 애플리케이션을 개선하거나, 작업 중인 부서 또는 영역에서 작업 중인 여러 워크로드를 파악하는 데 활용할 수 있습니다.

SaaS 렌즈는 AWS Regional Services List에 설명된 대로 AWS Well-Architected Tool을 사용할 수 있는 모든 리전에서 사용할 수 있습니다. AWS Well-Architected Tool은 무료로 사용할 수 있습니다.

AWS 고객인 경우 검토를 수행할 수 있는 AWS 파트너를 찾으려면 AWS Well-Architected Partners와 AWS SaaS Competency Partners를 확인하시길 바랍니다.

AWS 기술 블로그