Amazon ElastiCache for Redisの通信暗号化とクライアント認証をやってみた | DevelopersIO

Amazon ElastiCache for Redisの通信暗号化とクライアント認証をやってみた | DevelopersIO

2017年10月末のアップデートにより、Amazon ElastiCache for Redis が通信の暗号化とクライアント認証に対応しました

通信の暗号化(encryption in-transit)を使うと

  • アプリとRedis間の通信(encrypted connections)
  • プライマリ↔レプリカなどのRedis間の通信(encrypted replication)

が暗号化されます。

redis-in-transit-encryption

また、Redis の AUTH コマンドによるクライアント認証にも対応したため、認証レベルを強化できます。

これらの機能追加により、個人を特定できる情報(PII)など機密度の高い情報を扱うシステムでAmazon ElastiCache for Redisを導入しやすくなりました。

それでは、実際に使ってみましょう。

なお、同時に機能追加された、保管時の暗号化は次のブログをご確認下さい。

通信の暗号化

Redis の公式ドキュメント “Redis Security” では “Redis general security model” について次のように記載されています。

Redis is designed to be accessed by trusted clients inside trusted environments.

この前提の上で、Redis サーバーとは TCP や UNIX ソケットで通信します。

一方で、よりセキュアなシステムが求められるシステムには、 Redis Labs が提供する Redis Enterprise Pack (RP)のような通信の暗号化に対応した Redis が利用されてきました。

今回の機能追加は

  • 通信の暗号化(TLS 1.2)
  • 追加費用なし
  • サーバ証明書の発行・更新も含めてフルマネージド

で提供するというものです。

クライアントとサーバー間(encrypted connections)だけでなく、プライマリ↔レプリカのようにRedis間の通信(encrypted replication)も含めて暗号化されます。

TLS 通信には AmazonがOSSとして開発する S2N が利用されている点も見逃せません。

設定

Redisクラスター作成時に「Encryption in-transit」をチェックするだけです。

redis-encryption-3.2.6 only

2017/11/15時点では、最新の 3.2.10 では利用出来ません。お気をつけ下さい。

Enables encryption of data on-the-wire. Currently, enabling encryption in-transit can only be done when creating a Redis cluster using Redis version 3.2.6 only.

作成済みのクラスターで有効にすることは出来ません。クラスターの再作成が必要です。

サーバー接続を試す

Redisクラスター作成後、実際に接続を試してみましょう。

telnet コマンドから試す

Redis への通信が暗号化されていない場合の接続方法は、過去に次のブログにまとめました。

telnet で暗号化されたRedisに接続してみましょう。

1

2

3

4

5

6

$ telnet $REDIS-ENDPOINT 6379

Trying 172.31.31.65...

Connected to dummy.euc1.cache.amazonaws.com.

Escape character is '^]'.

PING

Connection closed by foreign host.

telnet は TLS をしゃべれないので接続をきらめました。

openssl コマンドから試す

TLS 通信のクライアントとして、Linux 系 OS であれば必ず入っている openssl を利用します。

Redis クラスターのエンドポイントに接続し、PING コマンドを実行します。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

$ HOST=REDIS-ENDPOINT

$ openssl s_client -connect $HOST:6379 -quiet

depth=4 C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority

verify return:1

depth=3 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2

verify return:1

depth=2 C = US, O = Amazon, CN = Amazon Root CA 1

verify return:1

depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon

verify return:1

depth=0 CN = *.security.dummy.euc1.cache.amazonaws.com

verify return:1

+OK

PING

+PONG

無事 PONG がかってきました。

サーバーの証明書も確認してみましょう

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

$ openssl s_client -connect $HOST:6379 < /dev/null

CONNECTED(00000003)

depth=4 C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority

verify return:1

depth=3 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2

verify return:1

depth=2 C = US, O = Amazon, CN = Amazon Root CA 1

verify return:1

depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon

verify return:1

depth=0 CN = *.xxx.dummy.euc1.cache.amazonaws.com

verify return:1