Redis 6 New-Feature🎉

ACL

레디스의 ACL(Access Control List)은 특정 커넥션에 대해 커맨드와 키에 대한 접근 권한을 관리하는 기능이다. 커넥션을 맺은 뒤 유저의 이름과 패스워드를 인증하는 방식으로 작동한다. 인증이 성공하면 이 커넥션은 특정 유저와 연결되며 유저는 제한적으로 동작할 수 있게 된다. 첫 연결이 기본 유저로 맺어지고, 기본 유저는 명시적으로 인증되지 않았지만 기능의 일부분을 사용할 수 있다는 부작용을 가지고 있다.

기본 구성에서 레디스6은 이전 버전과 똑같이 작동한다. 새로운 모든 커넥션은 가능한 모든 커맨드를 호출하고 모든 키에 액세스 할 수 있으므로 ACL 기능은 이전의 클라이언트 및 애플리케이션과 역호환된다. 또한 이전 버전에서 패스워드를 구성하던 방식인 requirepass를 여전히 사용할 수 있지만, 이 방법은 기본 사용자에 대한 암호를 설정하는것으로만 여겨진다.

레디스6에서 AUTH 커맨드는 확장되었으며, 다음과 같이 두 개의 인자를 받을 수 있다.

AUTH <username> <password>

이전 버전의 호환성을 위해 아래처럼 사용할 수도 있다.

AUTH <password>

인증에 사용된 사용자의 이름이 “default” 이므로 패스워드만 입력하는 것이 기본 사용자에 대한 인증으로 받아들여진다. 따라서 이전 버전과의 완벽한 역호환성을 제공한다고 볼 수 있다.

When ACLs are useful

ACL을 사용하기 전에, 이 기능을 사용해서 얻고자 하는게 무엇인지를 먼저 생각해보자. 일반적으로 다음 두 가지 기능을 위해 ACL을 사용한다.

또 다른 ACL의 사용 예제는 레디스 인스턴스를 관리하는 것에 있다. 보통 회사 내에서 레디스를 사용할 때에는 회사 내의 인프라를 관리하는 팀에서 레디스 인스턴스를 제공받거나, 다른 클라우드 서비스를 이용해서 SAAS로 레디스를 제공받는다. 두 경우 모두 레디스를 발급받는 사용자는 레디스 구성에 대한 커맨드는 제외되었는지 확인할 필요가 있다. 이전 버전에서 커맨드의 이름을 바꿀 수 있었던 기능은 ACL 기능 없이 사용하기 위한 트릭이었지만 완벽하게 이상적인 방법은 아니었다.

Configuring ACLs using the ACL command

ACL은 특정 사용자가 특정 액션을 할 수 있는지, 없는지를 설명하는 DSL(Domain Specific Language)를 이용하여 정의된다. 사용자가 실제로 수행할 수 있는 것을 이해하려면 DSL의 나열 순서를 지키는 것이 중요하다. 항상 처음부터 마지막, 왼쪽에서 오른쪽으로 실행된다.

처음 레디스 서버를 시작하면 한 개의 기본 유저(default user)를 확인할 수 있다. ACL LIST 커맨드를 사용해서 현재 활성 ACL을 확인하고 기본값으로 시작된 레디스 인스턴스를 확인할 수 있다.

> ACL LIST
1) "user default on nopass ~* +@all"

이 커맨드는 사용자에 할당된 현재의 ACL 규칙을 구성파일에서 확인하는 것과 똑같은 형식으로 보여준다.

각 행의 처음 두 단어는 “user” 그리고 사용자명이다. 다음 단어는 다른 ACL 규칙을 정의한다. 규칙이 어떻게 작동하는지는 뒤에 자세히 설명하겠지만, 일단 기본 유저는 활성(on) 상태, 비밀번호 없이(nopass), 모든 가능한 키에 접근(~*), 그리고 모든 커맨드를 수행(+@all) 할 수 있다는 것을 의미한다.

또한, 기본 유저의 경우 nopass 규칙이 있기 때문에 AUTH 를 호출할 필요 없이 자동으로 커넥션을 만들 수 있음을 알 수 있다.

ACL rules

Enable and disallow users

on: 유저를 허용함: 이 유저는 접근이 가능하다고 명시함.
off: 유저를 허용하지 않음: 이 유저는 접근할 수 없지만, 이미 인증되어있는 연결은 여전히 작동함.

✔︎ NOTE
기본 유저에 대해 'off'로 설정을 한다면 사용자는 새로운 커넥션을 맺을 때 자동으로 인증되지 않으며, 기본 유저임에도 불구하고 항상 AUTH 커맨드를 통해 권한을 인증해야 한다.

Allow and disallow commands

+<command>: 유저가 실행할 수 있는 커맨드를 나열
-<command>: 유저가 실행할 수 없는 커맨드를 나열
+@<category>: 유저가 실행할 수 있는 커맨드의 카테고리를 나열. 예를 들어 @admin, @set, @sortedset 등이 있을 수 있으며, 전체 리스트는 ACL CAT 커맨드를 이용해서 확인할 수 있다. @all 카테고리는 모든 커맨드를 뜻하며, 현재 서버뿐 아니라 나중에 모듈을 통해 로드될 커맨드 전부를 뜻한다.
-@<category>: 위와 비슷하지만 클라이언트에서 사용할 수 있는 카테고리 커맨드를 제한한다.
+|subcommand: 사용하지 않도록 설정된 커맨드의 특정 하위 커맨드는 허용한다는 의미. 여기서 나열한 커맨드가 이미 활성화되어 있다면 이 ACL은 에러를 발생시킨다.
allcommands: +@all 와 같은 뜻이다. 이 커맨드는 이후에 로드될 모든 모듈의 커맨드에 대해서도 허용한다는 것을 의미한다.
nocommands: -@all 과 같은 뜻이다.

Allow and disallow certain keys

~<pattern>: 커맨드의 일부로 언급할 수 있는 키 패턴을 추가한다. 예를 들어 ~*는 모든 키를 허용한다. 이 패턴은 KEYS와 마찬가지로 글로벌 스타일의 패턴이다. 복수의 패턴을 지정할 수 있다. * allkeys 는 ~* 와 같은 뜻이며, * resetkeys 는 허용된 키 패턴 목록을 버리라는 의미이다. 예를 들어 아래과 같은 규칙에서 클라이언트는 objects:* 의 패턴이 들어간 키에만 접근할 수 있다.

ACL ~foo:* ~bar:* resetkeys ~objects:*

Configure valid passwords for the user

><password>: 유저에 대한 패스워드 리스트에 이 패스워드를 추가한다. 예를 들어 >mypass는 mypass 라는 비밀번호를 유효한 패스워드 리스트에 추가한다. 이 명령은 nopass 플래그를 무효화한다. 모든 유저는 여러개의 패스워드를 가질 수 있다.
<<password>: 유효한 패스워드 리스트에서 이 패스워드를 삭제한다. 만약 유효한 패스워드 목록에 이 패스워드가 없다면 에러가 발생한다.
#<hash>: 이 SHA-256 해시값을 유효한 패스워드 리스트에 추가한다. 이 해시값은 접속을 시도하는 유저에 대해 입력한 비밀번호의 해시와 비교된다. 이를 통해 사용자는 일반 텍스트 암호를 저장하지 않고 acl.conf 파일에 해시를 저장할 수 있다. 패스워드에 사용되는 해시값은 64자의 16진수 문자값이어야 하기 때문에 SHA-256 해시 값만 허용된다.
!<hash>: 유효한 암호 목록에서 이 해시값을 제거한다. 이는 해시값으로 지정된 암호를 모르지만 사용자로부터 암호를 제거하고자 할 때 유용하다.
nopass: 기존의 모든 패스워드를 제거하고, 비밀번호가 필요하지 않는 것으로 지정된다. 이 지시어가 기본 유저에게 지정되는 경우, 모든 새 연결은 명시적인 AUTH 커맨드 없이 기본유저에 즉시 연결된다. resetpass 지시문은 이 조건을 삭제한다는 것에 유의해야 한다.
resetpass: 모든 패스워드를 제거하며, nopass 상태까지 지워버린다. 이 상태에서 사용자는 관련된 패스워드가 하나도 없으며, nopass 상태 또는 일부 패스워드를 추가하기 전까지 인증할 수 있는 방법이 없다.

✔︎ NOTE
nopass 플래그가 지정되지 않고, 유요한 암호 목록이 없다면 이 사용자로 로그인할 수 있는 방법은 없기 때문에 사실상 사용자에 대한 접근이 불가능한 상태이다.

Reset the user

reset 은 다음 액션을 수행한다. resetpass, resetkeys, off, -@all. 따라서 유저는 생성 직후와 동일한 상태로 돌아간다.

Creating and editing users ACLs with the ACL SETUSER command

유저는 다음의 두 가지 방법으로 생성되고, 수정될 수 있다.

ACL SETUSER 라는 ACL 커맨드를 사용
유저를 정의하는 서버의 구성파일을 변경한 뒤 서버를 재시작시키거나, 외부의 ACL파일을 사용한 뒤 ACL LOAD 커맨드를 사용한다.

이 장에서 우리는 ACL 커맨드를 사용해서 유저를 정의하는 방법에 대해서 공부할 것이다. 이 방법을 알고 나면 구성파일을 이용해서 유저를 정의하는 것은 쉽게 할 수 있을 것이다. 이는 나중에 다른 섹션에서 설명하겠다.

간단한 ACL SETUSER 커맨드를 시도해보자.

> ACL SETUSER alice
OK

SETUSER 커맨드는 유저명과 유저에게 적용할 ACL 규칙을 나열한다. 하지만 위의 예에서는 규칙을 명시하지 않았는데, 이럴 때에 만약 유저가 존재하지 않았다면 기본 규칙을 유저에게 부여한다. 유저가 이미 존재한다면 위의 커맨드는 아무런 일도 하지 않는다.

기본 유저의 상태를 알아보자.

> ACL LIST
 1) "user alice off -@all"
 2) "user default on nopass ~* +@all"

방금 만든 유저 alice의 상태는 다음과 같다.

off 상태이며, 따라서 비활성화 상태이다. AUTH 커맨드는 작동하지 않는다.
아무 커맨드도 실행할 수 없다. 사용자가 어떤 커맨드도 액세스할 수 없는 상태로 기본적으로 생성되므로 위의 출력에서 -@all 을 생략할 수 있지만, ACL LIST에서는 명시적으로 노출했다.
결론적으로, 이 유저가 접근할 수 있는 키 패턴은 없다.
유저는 접속 가능한 패스워드도 없다.

지금 상태의 유저로는 아무 것도 할 수 없다. 이제 유저를 사용 가능하도록 패스워드도 만들고, ‘cached:’ 프리픽스로 시작하는 키를 GET 할 수 있도록 접근권한을 부여해보자.

> ACL SETUSER alice on >p1pp0 ~cached:* +get
OK

이제 유저는 일부 권한을 가졌지만, 일부에 대해서는 권한이 없다.

> AUTH alice p1pp0
OK
> GET foo
(error) NOPERM this user has no permissions to access on of the keys used as arguments
> GET cached:1234
(nil)
> SET cached:1234 zap
(error) NOPERM this user has no permissions to run the 'set' command or its subcommand

위의 예제에서 ACL 규칙은 우리가 예상한 대로 잘 작동되는 것을 확인할 수 있다. alice라는 유저(유저명은 대소문자를 구분함)의 현재 권한을 확인하기 위해 ACL LIST를 대체한 다른 커맨드를 사용할 수도 있다. ACL LIST는 사람이 읽기에는 조금 복잡하다.

> ACL GETUSER alice
1) "flags"
2) 1) "on"
3) "passwords"
4) 1) "2d9c75..."
5) "commands"
6) "-@all +get"
7) "keys"
8) 1) "cached:*"

ACL GETUSER 커맨드는 필드-값 배열을 반환하며 이 유저를 조금 더 이해하기 쉽도록 보여준다. 결과값은 플래그 세트, 주요 패턴 목록, 암호 등을 포함한다. RESP3을 사용할 경우 아래처럼 더 읽기 쉽게 맵으로 반환한다.

> ACL GETUSER alice
1# "flags" => 1~ "on"
2# "passwords" => 1) "2d9c75..."
3# "commands" => "-@all +get"
4# "keys" => 1) "cached:*"✔︎ NOTE
이제부터 우리는 레디스의 기본 프로토콜인 version 2를 사용할 것이다 왜냐하면 커뮤니티에서 새로운 프로토콜로 전환하는 데에 시간이 걸릴 것이기 때문이다.

이제 다시 ACL SETUSER 커맨드를 사용해서 유저에게 더 많은 규칙을 적용해보자.

> ACL SETUSER alice ~objects:* ~items:* ~public:*
OK
> ACL LIST
1) "user alice on >2d9c75... ~cached:* ~objects:* ~items:* ~public:* -@all +get"
2) "user default on nopass ~* +@all

What happens calling ACL SETUSER multiple times

ACL SETUSER를 여러번 사용했을 때 어떻게 반영되는지 이해해야 한다. 가장 중요한 것은 SETUSER 커맨드를 사용하면 계속 기존 유저에 룰이 추가되지, 기존 유저가 초기화되지 않는다는 것이다. 유저는 기존에 알려지지 않았을 경우에만 재설정된다. 새로운 유저가 생성되면 zero-ACL 상태이며, 유저는 아무것도 할 수 없고, 비활성화되어 있으며, 암호가 없는데, 이는 보안을 위한 최고의 설정이다.

그 유저를 사용하려면 추후에 아래의 방법을 따라 점진적으로 규칙을 수정해 나가야 한다.

> ACL SETUSER myuser +set
OK
> ACL GETUSER myuser +get
OK

이후 myuser는 GET과 SET을 모두 할 수 있게 된다.

> ACL LIST
1) "user default on nopass ~* +@all"
2) "user myuser off -@all +set +get"

Playings with command categories

유저가 사용 가능한 커맨드를 하나씩 지정하는 것은 너무 귀찮은 방법이다. 그래서 다음처럼 카테고리를 사용하면 편하다.

> ACL SETUSER antirez on +@all -@dangerous >42a979... ~*

+@all 와 -@dangerous 에서 알 수 있듯이 모든 커맨드를 추가했다가 레디스의 커맨드 테이블 내에 dangerous로 지정된 일부 커맨드를 삭제했다는 것을 알 수 있다. 커맨드 카테고리는 +@all을 제외하고는 모듈의 커맨드는 절대 포함하지 않는다는 것을 기억해야 한다. +@all 커맨드를 유저에게 부여한다면 나중에 모듈로 추가하는 시스템의 커맨드도 포함한다는 것을 의미한다. 하지만 ACL 규칙에 +@readonly 혹은 다른 커맨드를 쓸 때에는 모듈의 커맨드는 항상 제외된다. 이는 레디스 내부의 커맨드 테이블을 신뢰해야 하기 때문에 중요하다. 모듈은 위험한 것을 노출할 가능성이 있으며, +@all -... 의 형태로 노출될 수 있다. 의도하지 않았던 것을 포함하지 않았다는 것을 확신해야 한다.

하지만 어떤 카테고리에 어떤 커맨드가 들어있는지를 기억하는 것은 불가능하기 때문에, 아래 ACL CAT 커맨드를 사용해서 이를 두가지 형태로 확인할 수 있다.

ACL CAT -- 존재하는 카테고리의 리스트만 나열
ACL CAT <category-name> -- 카테고리 내부의 모든 커맨드를 나열> ACL CAT
 1) "keyspace"
 2) "read"
 3) "write"
 4) "set"
 5) "sortedset"
 6) "list"
 7) "hash"
 8) "string"
 9) "bitmap"
10) "hyperloglog"
11) "geo"
12) "stream"
13) "pubsub"
14) "admin"
15) "fast"
16) "slow"
17) "blocking"
18) "dangerous"
19) "connection"
20) "transaction"
21) "scripting"

위의 결과에서 확인할 수 있듯이 총 21개의 카테고리가 존재한다. geo 카테고리에는 어떤 커맨드가 포함되는지 확인해보자.

> ACL CAT geo
1) "geohash"
2) "georadius_ro"
3) "georadiusbymember"
4) "geopos"
5) "geoadd"
6) "georadiusbymember_ro"
7) "geodist"
8) "georadius"

커맨드는 여러 카테고리에 속할 수 있다. 예를 들어 +@geo -@readonly 라는 ACL 규칙으로 인해 몇 개의 geo 커맨드는 read-only 규칙으로 인해 사용할 수 없게 된다.

Adding subcommands

커맨드 전체를 포함하거나 제외하는것만으로는 충분하지 않을 때가 있다. 많은 레디스 커맨드들은 인수를 포함한 서브커맨드로 다양한 작업을 할 수 있다. 예를 들어 CLIENT 커맨드는 위험하게도, 위험하지 않게도 사용 가능하다. 어드민 레벨이 아닐 때 CLIENT KILL 은 사용할 수 없도록 하고싶지만, 그들이 CLIENT SETNAME은 사용가능하도록 하고싶을 수도 있다.

이 때 ACL 커맨드에 다음과 같은 룰을 추가할 수 있다.

ACL SETUSER myuser -clinet +client|setname + client|getname

처음에 CLIENT 커맨드는 모두 제외시켰지만, 이후에 두 개의 서브커맨드를 허용했다. 이 규칙에서 순서는 매우 중요하다. 서브커맨드는 제외가 불가능하고, 규칙을 허용하는 것만이 가능하다. 왜냐하면 이후에 새로운 서브커맨드들이 추가될 수 있기 때문이고, 유저별로 사용가능한 서브커맨드를 추가하는것이 더 안전하기 때문이다. 게다가, 이미 제외된 커맨드가 아닌 서브커맨드를 추가하려고 하면 ACL 규칙의 버그라고 여겨져서 에러가 발생된다.

> ACL SETUSER default +debug|segfault
(error) ERR Error in ACL SETUSER modifier '+debug|segfault': Adding a subcommand of a command already fully added is not allowed. Remove the command to start. Example: -DEBUG +DEBUG|DIGEST

서브커맨드를 추가하는 것이 약간의 성능 저하를 일으킬 수 있지만, 이런 패널티는 벤치마크 툴로도 측정하기가 매우 어렵고, 다른 커맨드가 아니라 해당 커맨드가 사용될 때에만 CPU를 조금 더 사용한다는 점을 알아야 한다.

How passwords are stored internally

레디스는 내부적으로 SHA256을 사용해서 패스워드를 저장한다. 만약 패스워드를 설정하고 ACL LIST 또는 GETUSER 를 통해 확인하고 싶다면 랜덤한 값의 hex 문자열을 보게 될 것이다.

> ACL GETUSER default
1) "flags"
2) 1) "on"
   2) "allkeys"
   3) "allcommands"
3) "passwords"
4) 1) "2d9c75273d72b32df726fb545c8a4edc719f0a95a6fd993950b10c474ad9c927"
5) "commands"
6) "+@all"
7) "keys"
8) 1) "*"

마찬가지로 이전의 커맨드인 CONFIG GET requirepass 는 레디스 버전 6부터는 해싱된 패스워드를 보여줄 것이다.
SHA256을 사용하면 패스워드 자체를 저장하는 것을 피하면서도 빠르게 AUTH를 사용할 수 있고, 이는 레디스의 클라이언트가 원하는 점이다.
하지만 ACL passwords는 실제로 패스워드가 아니다. 이 패스워드는 사람이 사용하는 인증 토큰이 아니기 때문이다.

길이 제한이 없다. 이 패스워드는 클라이언트 소프트웨어에 저장될 뿐이지, 사람이 기억할 필요가 없다.
ACL 패스워드는 다른 것을 보호하지 않는다. 예를 들어, 이메일 계정의 패스워드를 여기에 사용하지는 않을 것이다.
특정 서버의 레디스 커맨드에 대한 전체 액세스 권한을 얻었거나, 시스템을 무단으로 침입하여 해시된 암호 자체에 액세스할 수 있게 된 경우, 이미 암호를 통해서 보호하고자 하는 인스턴스 안전성과 레디스에 포함된 데이터에 액세스할 수 있는 상태이다.

따라서 시간과 공간을 더 차지하는 알고리즘으로 패스워드 인증 시간을 느리게 하는 것은 패스워드 크래킹이 심해지도록 할 수 있으며 매우 좋지 못한 선택이다. 차라리 강력한 패스워드를 만들어서 해시를 가지고 있는 사람조차도 딕셔너리나 brute force 공격을 사용해서 패스워드를 해독할 수 없도록 만드는 걸 제안한다. 이런 이유로 시스템의 암호화 슈도 제너레이터를 사용해서 비밀번호를 생성하는 특수 ACL 커맨드가 있다.

> ACL GENPASS
"dd721260bfe1b3d9601e7fbab36de6d04e2e67b0ef1c53de59d45950db0dd3cc"

커맨드는 32바이트의 랜덤한 슈도 스트링을 생성해서 64바이트의 영문과 알파벳 스트링으로 변환한다. 이는 공격에 방어하기 충분한 길이이며, 동시에 복사&붙혀넣기, 저장 등 관리하기에도 쉬운 길이이다. 이는 레디스에서 패스워드를 만들기 위해 사용해야 할 것이다.

Using an external ACL file

유저 정보를 레디스 구성파일에 저장할 수 있는 방법이 두 가지 있다.

redis.conf 파일 내에 저장
외부의 ACL파일에 저장

두 가지 방법은 호환되지 않으므로, 레디스는 당신에게 둘 중 어떤 방법을 사용할 것인지를 물어볼 것이다. redis.conf 파일 내에 유저의 정보를 저장하는 것은 제일 간단한 방법이다. 복잡한 환경에서 많은 유저를 지정하게 된다면, ACL 파일을 사용할 것을 권장한다.

redis.conf 와 외부의 ACL파일에서 유저를 정의하는 포맷은 동일하다. 따라서 하나에서 다른 하나로 변환하는 것은 간단하다.

user worker +@list +@connection ~jobs:* on >ffa9203c493aa99

만약 외부의 ACL파일을 사용하고 싶다면, 아래처럼 aclfile 파라미터를 지정해야 한다.

aclfile /etc/redis/users.acl

만약 몇몇의 유저들만 redis.conf 파일 내에 지정해서 사용한다면, CONFIG REWRITE 커맨드를 사용해서 새로운 유저 정보를 파일로 저장할 수 있다.

ACL 정보를 파일로 저장할 때에는 아래 두 커맨드를 사용할 수 있다.

ACL LOAD (/commands/acl-load) 를 사용해서 수정한 ACL 리스트를 서버로 불러올 수 있다. 모든 유저의 정보가 정확해야 제대로 작동해야 한다는 것에 유의해야 한다. 그렇지 않으면 이 커맨드는 에러를 반환하고, 기존의 ACL 리스트는 정상으로 남아있게 된다.
ACL SAVE (/commands/acl-save) 를 사용해서 현재의 ACL 구성을 파일에 저장한다.

✔︎ NOTE
CONFIG REWRITE 커맨드가 ACL SAVE 커맨드와는 상관이 없음을 유의해야 한다. ACL 리스트를 파일로 보관한다면 각각 커맨드를 실행해야 한다.

ACL rules for Sentinel and Replicas

만약 리플리카 인스턴스나 센티널 인스턴스를 마스터에 일부만 접근하도록 제한하고 싶다면, 다음 커맨드를 사용해야 한다.
센티널의 경우, 사용자가 마스터 및 리플리카 인스턴스에서 다음 커맨드에 액세스 할 수 있도록 해야한다.

AUTH, CLIENT, SUBSCRIBE, SCRIPT, PUBLISH, PING, INFO, MULTI, SLAVEOF, CONFIG, CLIENT, EXEC
센티널은 데이터베이스 내의 키에 접근할 필요가 없기 때문에, 규칙을 만들자면 아래와 같다.(언제나 접근가능하기 때문에 AUTH도 필요 없다.)

ACL setuser sentinel-user >somepassword *client *subscribe +publish +ping +info +multi +slaveof +config +client +exec on

레디스의 리플리카는 마스터 인스턴스에서 다음 커맨드를 허용해줘야 한다.

PSYNC, REPLCONF, PING
키에 접근할 필요는 없고, 따라서 다음 규칙으로 나타낼 수 있다.

ACL setuser replica-user >somepassword +psync +replconf +ping on

마스터가 모든 커맨드를 실행할 수 있도록 리플리카 인스턴스를 구성할 필요는 없다는 점에 유의해야 한다. 마스터는 항상 복제본 관점에서는 루트 사용자로 인식된다.

레디스 ACL

댓글