인사이트리포트

들어가며

[그림1]  클라우드: RBAC

 

클라우드 시대의 RBAC 보안

클라우드 시대의 RBAC 보안은 단순한 인증(Authentication)을 넘어서, 정교한 권한 관리(Authorization)로 확장되며, AWS, Azure 및 GCP와 같은 클라우드 플랫폼에서 넓게 활용되고 있다.

RBAC은 사용자에게 직접 권한을 부여하지 않고, 사용자의 역할(Role)에 권한을 부여하며, 사용자는 해당 역할을 통해 리소스에 접근하는 방식이다.

 

동시성 제어는 왜 필요한가?

여러 개의 스레드가 공유 자원에 동시에 액세스하여 값이 예상과 다르게 변하여 문제가 발생하는 것을 경쟁 상태(Race condition)라고 한다. 이러한 상황에 데이터의 일관성을 해치는 결과가 나타날 수 있다.

RBAC 핵심 개념

■ 사용자(User): 시스템에 접근하는 주체 (사용자 또는 시스템 계정)

■ 역할(Role): 여러 개의 권한을 묶어놓은 집합

■ 권한(Permission): 시스템 리소스에 대한 접근 권한(읽기, 쓰기, 수정, 삭제 등)

■ 리소스(Resource): 시스템에서 보호해야 하는 데이터나 서비스

 

클라우드 환경에서 RBAC의 진화

■ 클라우드에서는 다음과 같은 특징으로 인해 RBAC을 재고할 필요성이 있다.

 

Redis는 RBAC을 어떻게 다루고 있을까?

[그림2] 동시성 이슈의 예

Redis는 고성능 인메모리 데이터 저장소로 캐시, 세션, 메시징 등 다양한 용도로 폭 넓게 활용되고 있다.

하지만, Redis 솔루션은 6버전 이전까지는 단일 사용자 인증 모델만 제공하면서, 아래와 같이 보안적 한계점이 있었다.

■ 모든 클라이언트가 동일한 비밀번호로 전체 Redis 명령과 key에 접근 가능

■ 사용자를 구분하거나 read/write 권한을 세분화할 수 없음

■ 위험한 명령어 (flushall, config, delete, keys 등)에 대한 제어 불가

■ 서비스 운영자, 개발자, 외부 시스템 간 권한 분리 불가능

■ SaaS/멀티테넌시 구조에서 데이터 격리와 보안 통제 어려움

 

이와 같은 한계는 특히 클라우드 환경의 확산, DevOps 자동화, 보안 규제 강화와 함께 실질적인 운영 리스크로 대두되었다.

 

이러한 보안적 과제를 해결하고, 보다 체계적인 권한 관리를 가능하게 하기 위해 Redis는 ACL(Access Control List)이라는 기능을 도입하였다.

 

Redis ACL 기반 RBAC 보안: Redis OpenSource & Redis Enterprise

Redis ACL이란 사용자에 대해 command와 key에 대한 접근 권한을 관리하는 기능이다.

Redis의 ACL 기능은 2020년에 Redis 6.0 버전에서 도입되었다. 이후, Redis Enterprise SW는 Redis OpenSource 6.0버전의 ACL 기반으로 RBAC 기능을 추가하여 보안을 강화하였다.

 

Redis OpenSource와 Redis Enterprise의 RBAC에 대해 기본 개념은 같지만, 기능 범위와 관리 편의성, 통합 지원 측면에서 차이가 있다.

 

Redis의 ACL은 RBAC(Role-Based Access Control)의 개념을 Redis에 적용하여 단순한 인증 보안의 강화 수준을 넘어, RBAC 기반으로 서비스 안정성과 운영 거버넌스를 확보하기 위한 도구이며, 사용 가능한 사용자 및 사용자 그룹을 생성하고 관리하는 기능을 제공한다.

 

 

Redis에서 꼭 알아야 할 ACL Command

ACL command는 Redis 6.0부터 도입된 사용자 인증 및 권한 제어(ACL: Access Control List) 기능을 제어하기 위한 command이다.

이 기능을 통해 Redis는 사용자 단위로 command, key, pattern, access 등을 제한할 수 있다.

 

Redis의 ACL CAT은 command 카테고리 분류 기능으로, ACL에서 사용자 권한을 설정할 때 핵심적으로 쓰이는 ACL command이다.

ACL command 중 CAT에 대해 제대로 이해하고 있으면, 복잡하게 명령어 하나하나 지정하지 않고, 안전하고 체계적인 사용자 권한 관리가 가능하다.

 

ACL CAT에 대해 알아보겠다.

 

■  ACL CAT (Command 카테고리) 명령을 사용하여 모든category 목록과 각 category에 포함된 정확한 command를 확인할 수 있다.

• ACL CAT: 사용 가능한 모든 category 목록예시)

  

■  ACL CAT <category-name>: category 내의 모든 command 목록

예시) ACL cat keyspace
@keyspace는 Redis에서 key 또는 key에 대한 메타데이터를 다루는 명령어들을 포함하는 category이다.
이 category는 key에 대한 개수확인, 만료 시간, 존재 여부 확인 등에 대한 command를 포함한다.

 

 

Redis OpenSource와 Redis Enterprise, ACL 함께 사용할 수 있을까?

Redis 제품군 간 ACL 기능 및 명령어 호환성 분석

Redis Enterprise에서는 다수 ACL 명령을 제한하고 있다.

※ Redis OpenSource의 모든 ACL command는 Redis Enterprise에서 완전히 호환되는 것은 아니다.

 

Redis Enterprise의 cluster는 Redis OpenSource와 다른 방식의 동작과 내부 구조적 차이로 인해 Redis Enterprise의 클러스터 명령어 자체를 Supported/Not Supported 구분 없이 전체 비호환 명령어로 금지시켜 놓았다.

 

■  Redis Enterprise는 클러스터가 관리 서버에 의해 중앙에서 관리되며, 내부적으로 데이터베이스 단위 및 Master/Replica 샤드가 구성된다.

■  Redis OpenSource에서 사용하는 Cluster 명령어 대부분은 Redis Enterprise에서는 제한적으로 동작한다.

■  Redis Enterprise에서 차단된 클러스터 command를 사용하려고 하면 오류가 발생한다.

 

단, Redis Enterprise는 OSS Cluster API 활성화 여부에 따라 “Supported”로 표기된 command를 지원하고 있다.

아래의 예시)와 같이 cluster command 중 일부 command 경우, “OSS Cluster API”가 활성화된 상태에서만 지원된다.

■  예시) CLUSTER INFO, CLUSTER KEYSLOT, CLUSTER NODES, CLUSTER SLOTS 등

■  “OSS Cluster API” 옵션은 Redis Enterprise의 아키텍처와 클라이언트의 접속 방식에 따라 결정된다.

■  추가적으로 “OSS Cluster API” 관련하여 Redis Enterprise Doc에서 확인할 수 있다.

 

Redis ACL 설정 시 꼭 알아야 할 Patterns

Redis에서 ACL pattern은 사용자 권한을 세밀하게 제어할 수 있는 기능 중 하나로, 특정 명령어나 key pattern에 대한 접근 권한을 설정할 수 있다.

Redis ACL 구성법, 예제 중심으로 살펴보기

[Redis OpenSource]

사용자 등록 및 role 적용

• SETUSER 사용자 user1을 생성
• on 옵션으로 사용자 활성화
• >qew123 사용자 비밀번호를 qwe123으로 설정
• ~USER:* 패턴으로 시작하는 key에만 접근 가능
• SET 및 GET command 허용

 

 

허용되는 command:

차단되는 command:

 

[Redis Enterprise]

Redis Enterprise는 보안 및 권한 관리를 위해 Users, Roles, Redis ACLs를 분리해서 사용한다.

Redis OpenSource와 달리 Redis Enterprise는 Admin UI를 제공하므로, UI에서 Access Control – Redis ACLs에서 규칙을 설정할 수 있다.

 

1. Redis ACLs 설정

Redis의 command 제어, key pattern 접근 제어 등을 정의

 [그림3] Redis Enterprise: ACLs 구성

 

■  관리 command 제외 : -@admin, -@dangerous

■  읽기 관련 명령어 그룹 허용 : get, hget, exists 등

■  ~*: 모든 key에 대한 접근 허용 (key pattern: *)

 

2 .Roles 적용

여러 사용자에게 동일한 권한을 쉽게 적용할 수 있으며, Role 안에 Redis ACL 규칙을 포함한다.

[그림4] Redis Enterprise: Roles 설정

 

3. User에 해당 Role 설정

실제 Redis에 접속하는 사용자(애플리케이션, 개발자, 관리자 등)에 따라 Role을 설정하고, 사용자는 직접 명령어 권한을 설정하지 않고 Role에 할당된 ACL을 따른다.
DB_View_User에게 ReadOnly_role 할당

[그림5] Redis Enterprise: User에 role 적용

 

 

Redis ACL, 이런 상황에 유용하다!

1. 다수의 사용자 또는 애플리케이션이 Redis DB를 공유할 때

■  Redis를 여러 서비스나 사용자가 공유 인스턴스로 사용할 경우, 각 사용자에게 접근   권한을 분리해야 한다.

■ ACL을 이용해 key패턴 (~orders:*, ~users:*)이나 명령어 수준에서 사용자 간 충돌 방지가 가능하다.

예시)

MicroService A는 orders:* key만 접근 가능

MicroService B는 users:* key만 접근 가능

 

2. 읽기 또는 쓰기 전용 권한이 필요할 때

■ 일부 사용자 또는 서비스 조회(Read)만, 일부는 쓰기(Write)만 허용할 수 있다.

 

3. 운영 중 명령어 오남용을 방지하고 싶을 때

■  운영자의 실수로 인해 Redis에 심각한 문제를 끼치는 것을 방지하기 위해 일부 명령 제한한다.

예시)

Redis에서 특정 job의 지연 때문에 전체 데이터를 삭제하는 FLUSHALL command를 잘못 실행하는 실수를 예방할 수 있다.

 

4. 다중 테넌트(Multi-tenant) 환경 구성 시

■  하나의 Redis 인스턴스를 여러 사용자(테넌트)가 사용할 때, 각 테넌트가 자신의 데이터만 접근하도록 보장해야 한다.

■  ACL로 key패턴 (~tenant123:*) 별로 권한을 설정하면 논리적 격리가 가능하다.

예시)

tenant123:session, tenant456:user:1 이러한 패턴으로 key 이름을 구성한다.

 

Redis ACL 활용을 위한 모범 사례

Access Control

■  ACL을 활용하여 클라이언트가 실행할 수 있는 명령을 제한한다.

■  사용자 별로 허용 명령어, 접근 key pattern 등을 분리한다.

■ keys, flushall, config, getcollection 관련 명령어 등 위험한 명령어는 차단한다.

 

Redis Enterprise Active-Active

■ Active-Active 환경일 경우, ACL role과 권한은 Active-Active(participating) 클러스터 간에 동일해야 한다. 다른 클러스터로 failover 중에 계정 ACL 이슈가 발생하는 것을 방지할 수 있다.

 

Disable default user

■  default user는 redis databases의 보안 액세스를 위한 구성된 권한이 없기 때문에 사용하지 않는 것을 권장한다.

 

 

활용 사례

[Case Study: 에스코어의 Redis 기술지원 사례]

S카드사 M앱 Redis OpenSource ACL 사례)

■ Redis 모니터링을 위한 ReadOnly ACL 계정 생성 (develop)

▶  develop(DB View) 계정 – 조회 및 권한 확인

    develop 사용자는 data 조회만 가능하고 data 삭제 시 permission error 발생

 

[그림6] Redis Insight: Redis OpenSource 권한 확인

 

S카드사 M앱 Redis Enterprise ACL 사례)

■ Redis 모니터링을 위한 ReadOnly ACL 계정 생성 (develop)

Redis Enterprise의 ACL role:

▶ develop(DB View) 계정 – 조회 및 권한 확인
develop 사용자는 data 조회만 가능하고 data 삭제 시 permission error 발생

[그림7] Redis Insight: Redis Enterprise 권한 확인

* 본 사례에서는 Redis Insight를 활용하였으며, 해당 도구는 사용자 편의를 위한 인터페이스이며 운영 시 효율적으로 활용할 수 있다.

 

 

마치며

지금까지 Redis에서 RBAC 보안을 구현하기 위해 ACL을 기반으로 사용자 별 접근 권한을 세분화하여 관리하는 방법을 살펴보았다. ACL을 활용하면 사용자 및 애플리케이션 단위로 최소 권한 원칙(Principle of Least Privilege)을 보다 정밀하게 적용할 수 있다.

 

또한, ACL을 최적화함으로써 멀티테넌시 환경 또는 마이크로서비스 아키텍처에서 발생할 수 있는 권한 오용 이슈를 최소화할 수 있으며, 이는 클라우드 기반 애플리케이션의 전반적인 보안 수준을 높이는데 기여 한다.

 

Redis는 단순한 캐시 서버로 시작할 수 있지만, 고가용성(HA), 복제(Replication), 클러스터링, 성능 최적화, 보안 설정 등이 요구되는 경우 운영 복잡도가 크게 증가한다. 이러한 환경에서는 고급 기술에 대한 전문 지식과 경험을 갖춘 IT 컨설팅 조직 또는 전문가 인력을 확보하는 것이 필요하다. 이를 통해 Redis는 고객 비즈니스의 만족과 성공을 실질적으로 지원하는 핵심 인프라로 자리잡을 수 있다.