TIL

11장 보안

• 레디스는 관계형 데이터베이스만큼 보안 관리가 필요하다.
  • 캐시로 사용할 경우 캐시에 접근한다는 것은 db에 접근한다는 것과 동일한 효력을 지닌다.
  • pub/sub 혹은 MQ로서 사용하더라도 데이터의 중간 전달자 역할을 하기에 데이터는 더 안전하게 보관되어야 한다.

커넥션 제어

bind

• 레디스 인스턴스는 여러 개의 네트워크 인터페이스를 가질 수 있다.
• bind 설정은 여러 ip 중 어떤 ip를 통해 연결을 받아들일 것인지 지정한다.
• 서버 외부와 연결이 필요한 경우 bind 값을 외부 ip로 명시적으로 설정해야 한다.
  • 특정 IP 외에 연결을 방지하는 보안적 설정을 권장한다.

패스워드

• 레디스에서는 패스워드 설정에 두 가지 방법을 사용할 수 있다.
  • 노드에 직접 패스워드를 지정
  • 6.0 버전에 새로 추가된 ACL(Access Control List) 기능 사용
• 이전 버전에선 requirepass를 사용해 레디스 서버에 패스워드를 설정할 수 있다.

127.0.0.1:6379> CONFIG SET requirepass password
OK

Protected mode

• protected mode는 레디스를 운영 용도로 사용한다면 설정하는 것을 권장한다.
• protected mode=yes
  • 패스워드를 설정하지 않았다면 로컬에서의 연결만 허용한다.
• 즉 패스워드를 사용하지 않을 때는 protected mode를 no로 변경해야 한다.

커맨드 제어

• 대부분의 레디스 파라미터는 CONFIG SET 커맨드로 재설정할 수 있다.
• 운영자가 커맨드라인으로 인스턴스를 제어하면 편리하지만 보안적으로는 위험할 수 있다.

커맨드 이름 변경

• rename-command
  • 레디스에서 특정 커맨드를 다른 이름으로 변경하거나 비활성화할 수 있는 설정
  • 커맨드를 커스터마이징하여 보안을 강화하는데 도움이 된다.
  • redis.conf 파일에서 변경 가능하며 실행 중에는 동적으로 변경할 수 없다.
• 센티널을 사용한다면 신경 써야 할 사항이 있다.
  • 센티널이 자체적으로 커맨드를 날려 이스턴스를 제어하는 경우가 있다.
  • 만약 커맨드 이름을 변경했다면 페일오버가 정상적으로 발생하지 않게 된다.
  • 따라서 redis.conf에서 변경한 커맨드는 sentinel.conf에서도 변경해야 한다.

커맨드 실행 환경 제어

• 레디스 버전 7부터는 보안 강화를 위해 특정 커맨드를 실행하는 환경을 제어할 수 있게 되었다.
• enable-protected-configs no
  • 레디스 기본 경로 설정인 dir 및 백업 파일 경로를 지정하는 dbfile 등 옵션을 CONFIG로 수정하는 것을 차단하는 옵션
• enable-debug-command no
  • DEBUG 커맨드를 차단
  • 레디스를 디버깅할 때 사용
• enable-module command
  • MODULE 커맨드 수행을 차단
• 위 세 설정 파일은 일반적으로 잘 사용하지 않는 커맨드이기에 공격 가능성을 줄이기 위해 아래와 같은 값으로 변경할 수 있다.
  • no: 모든 연결에 대해 명령어 수행을 차단
  • yes: 모든 연결에 대해 명령어 수행을 허용
  • local: 로컬 연결에 대해서만 명령어 수행이 허용된다.

ACL

• ACL (Access Control List)
  • 유저별로 실행 가능한 커맨드와 접근 가능한 키를 제한하는 기능
  • 레디스 버전 6에서 도입

유저의 생성과 삭제

• 유저 관련 커맨드
  • ACL SETUSER - 유저를 생성하는 커맨드
  • ACL DELUSER - 유저를 삭제하는 커맨드
  • ACL GETUSER - 특정 유저를 확인하는 커맨드
  • ACL LIST - 레디스에 생성된 모든 유저를 확인
• 레디스 설치 후 아무런 패스워드와 유저를 생성하지 않았다면 기본 유저가 생성된다.
• 기본 유저는 다음과 같은 권한과 특징을 가진다.
  • 유저 이름: default
  • 유저 상태: on(활성 상태)
  • 유저 패스워드: nopass(없음)
  • 유저가 접근할 수 있는 키: ~*(전체 키)
  • 유저가 접근할 수 있는 채널: &*(전체 채널)
  • 유저가 접근할 수 있는 커맨드: +@all(전체 커맨드)
• 레디스 ACL규칙은 항상 왼쪽에서 오른쪽에서 적용되기에 권한을 적용하는 순서가 중요하다.

유저 상태 제어

• 유저 활성 상태는 on과 off로 제어할 수 있다.
  • on이라는 구문 없이 유저를 생성하면 기본으로 off 유저가 만들어진다.
  • 생성 구문에 on을 명시하거나 acl setuser <username> on 구문을 추가해야 한다.

패스워드

• 패스워드 설정

  • 패스워드 키워드로 패스워드를 지정할 수 있다.

  • <패스워드 키워드로 지정한 패스워드를 삭제할 수 있다.
• 유저에 nopass 권한을 부여하면 패스워드 없이 접근할 수 있다.
• 유저에 resetpass 권한을 부여하면 유저에 저장된 모든 패스워드가 삭제된다.
  • nopass 상태도 없어짐
  • 유저에 대해 resetpass를 사용하면 다른 패스워드나 nopass 권한을 부여하기 전까진 그 유저에 접근할 수 없다.

패스워드 저장 방식

• ACL을 사용하지 않고 requirepass만 사용해서 패스워드를 정의하면 패스워드가 암호화되지 않은 채로 저장된다.
  • CONFIG GET requirepass 커맨드로 누구나 패스워드를 확인할 수 있게 된다.
• ACL로 패스워드를 저장하면 내부적으로 SHA256 방식으로 암호화돼 저장된다.
  • 패스워드 정보를 바로 조회할 수 없다.

커맨드 권한 제어

• ACL 기능으로 유저가 사용할 수 있는 커맨드를 제어할 수 있다.
  • 일부 커맨드는 그룹화되어 있어 커맨드를 일일이 직접 제어할 필요가 없다.
  • 개별 커맨드를 제어하는 것도 가능하다.
• 커맨드 권한 제어 키워드
  • +@all 혹은 allcommands 키워드는 모든 커맨드의 수행 권한을 부여한다는 것을 의미
  • -@all 혹은 nocommands는 아무런 커맨드를 수행할 수 없다는 것을 의미
  • 커맨드 권한을 지정하지 않으면 -@all 권한의 유저가 만들어진다.
  • +@로 특정 카테고리의 권한을 추가할 수 있다.
  • +로 개별 커맨드 권한을 추가할 수 있다.

> ACL SETUSER user1 +@all -@admin +bgsave +slowlog|get

• ACL 룰은 왼쪽에서 오른쪽으로 순서대로 적용된다.
  • 위 룰은 user1에 모든 커맨드 권한을 부여한 뒤 admin 카테고리 커맨드 권한은 제외한다.
  • 그리고 bgsave 커맨드와 slowlog 커맨드 중 get이라는 서브 커맨드에 대한 권한만 추가로 부여
• ACL CAT 커맨드를 이용해 미리 정의돼 있는 카테고리 커맨드 list를 확인할 수 있다.

키 접근 제어

• 유저가 접근할 수 있는 키도 제어할 수 있다.
  • 프리픽스 규칙을 미리 정해두고 특정 프리픽스를 가진 키에만 접근하도록 제어할 수 있다.
• 키 권한 부여 키워드
  • ~* 혹은 allkeys 키워드로 모든 키에 접근 가능하게 한다.
  • ~을 이용해 접근 가능한 키를 정의할 수 있다.
    • ex) ~mail:* 권한을 부여하면 mail:로 시작하는 모든 키에 대한 접근 권한을 부여한다는 것을 의미
• 읽기/쓰기 권한
  • %R~ : 키에 대한 읽기 권한
  • %W~ : 키에 대한 쓰기 권한
  • %RW~ : 읽기, 쓰기 권한 부여

셀렉터

• 버전 7 이후 좀 더 유연한 ACL 규칙을 위해 셀렉터가 도입됐다.

ACL SETUSER loguser ~log:* %R~mail:* %R~sms:*

• 위 커맨드는 유저에게 log: 프리픽스에 대한 모든 접근 권한을 부여하지만 mail:이나 sms:에 대해서는 읽기 권한만 부여한다.
  • 하지만 위 경우엔 mail:1 키에 대한 메타데이터도 조회할 수 있다.
    • 키 만료 시간 조회 등
• 특정 프리픽스 커맨드에 대해 오직 GET 커맨드만 사용하도록 강제하고 싶을 때 셀렉터를 사용할 수 있다.

ACL SETUSER loguser resetkeys ~log:* (+GET ~mail:*)

• 위 명령의 괄호 안에 정의된 것이 셀렉터다.
  • loguser에 정의된 모든 키를 리셋
  • log: 에 대한 모든 권한을 부여
  • mail:에 대해 get만 가능하도록 설정

pub/sub 채널 접근 제어

• & 키워드로 pub/sub 채널에 접근할 수 있는 권한을 제어할 수 있다.
• 전체 pub/sub 채널에 접근할 수 있는 권한 부여
  • all channels 또는 &* 키워드
• 어떤 채널에도 pub/sub할 수 없게 하는 키워드
  • resetchannels
  • 유저는 생성될 때 기본적으로 resetchanels 권한을 부여받는다.

유저 초기화

• reset 커맨드
  • 유저에 대한 모든 권한을 회수 및 기본 상태로 변경
  • ACL SETUSER를 한 직후와 동일해진다.

ACL 규칙 파일로 관리하기

• ACL 규칙은 redis.conf 파일로 관리할 수 있다.
  • ACL 파일을 따로 관리하는 것도 가능
  • ex) etc/redis/users.acl 파일로 ACL 파일을 관리하고 redis.conf에 다음 커맨드를 추가하면 된다.

aclfile /etc/redis/users/acl

• CONFIG REWRITE
  • ACL 파일을 사용하지 않을 때 모든 레디스 설정값과 ACL 룰을 한 번에 redis.conf에 저장하는 커맨드
• ACL 파일을 따로 관리할 경우엔 운영 측면에서 조금 더 유용하다.
  • ACL LOAD나 ACL SAVE 커맨드로 유저 데이터를 레디스로 로드하는 것이 가능

SSL/TLS

SSL/TLS란?

• SSL (Secure Sockets Layer) : 암호화를 위한 인터넷 기반 보안 프로토콜
• TLS (Transport Layer Security) : 현재 널리 사용되는 보안 프로토콜로 SSL에서 시작해 발전해왔다.
• 현재 대부분 애플리케이션에선 TLS를 사용하지만 SSL과 용어 사용이 종종 혼용되어 일반적으로 SSL/TLS라 통틀어서 부르기도 한다.
• SSL/TLS 특징
  • 데이터 전송 과정에서 정보를 암호화
  • 클라이언트와 서버 간 안전한 핸드셰이크 과정을 거치며 상호 신뢰할 수 있는지 확인
• 레디스는 SSL/TLS 통신을 적용해 네트워트를 통한 데이터 통신을 수행할 수 있다.

레디스에서 SSL/TLS 사용하기

• 레디스를 처음 빌드할 때 아래처럼 정의해야 SSL/TLS를 활성화시킬 수 있다.
  • make BUILD_TLS=yes
  • 기본적으로 레디스에선 SSL/TLS 설정이 비활성화돼 있다.
• SSL/TLS 프로토콜 사용 시레디스 인스턴스와 클라이언트 간 동일한 인증서를 사용해야 한다.
  • key, cert, ca-cert 파일을 클라이언트에 동일하게 복사해둬야 한다.
• certificates/keys 파일이 준비돼 있다는 가정하에 레디스 구성(redis.conf)은 다음과 같이 하면 된다.

tls-port <포트 번호>
tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
tls-ca-cert-file /path/to/ca.crt

• port와 tls-port
  • 이 두 포트를 모두 지정하면 각 포트를 통해 일반 통신과 TLS 통신을 모두 지원하게 된다.
  • 보안 강화를 위해 TLS 통신만 강제하고 싶다면 레디스 일반 포트를 0으로 명시하면 된다.

SSL/TLS를 사용한 HA 구성

• 복제 구성
  • SSL/TLS를 사용한다면 마스터와 마찬가지로 복제본도 tls 설정을 추가해야 한다.
  • 기본적으로 tls-replication은 no로 설정돼 있는데 이는 마스터-복제본 커넥션이 일반 프로토콜로 연결되기에 복제 연결을 구성할 수 없다.
  • tls-replication = yes를 명시해야 한다.

tls-port <포트 번호>

tls-replication yes

tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
tls-ca-cert-file /path/to/ca.crt

• 센티널 구성
  • sentinel.conf에도 복제본 구성에서 사용했던 구성 정보를 똑같이 추가하면 된다.
• 클러스터 구성
  • 아래와 같이 tls-cluster yes 구문을 추가하자
  • 모든 클러스터 노드 간 연결과 클러스터 버스 통신이 SSL/TLS 프로토콜로 보호된다.

tls-port <포트 번호>

tls-replication yes
tls-cluster yes

tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
tls-ca-cert-file /path/to/ca.crt