Redis TLS – Redis Enterprise 6.2.4のノード間暗号化を徹底解説

Redis Enterprise 6.2.4では、ノード間暗号化（Internode Encryption）機能が導入されました。この機能の目的は、Redisクラスター内のノード同士をつなぐすべての内部接続にTLS暗号化を実現することです。具体的には以下が対象となります。

1. コントロールプレーン接続の強化：CCS（Cluster Configuration Store）レプリケーションの暗号化
2. レプリカノードからプライマリノードのCCSへのすべての接続
3. データプレーン接続：ノード間のシャードレプリケーションの暗号化
4. ノード間におけるプロキシとシャード間のすべての接続

Redis Enterpriseの設計上の考慮事項

Redis Enterpriseは、パフォーマンスと可用性を最適化するために複数の技術を採用しています。Redisクラスターはシェアードナッシング（shared-nothing）アーキテクチャを採用しており、これにより信頼性と可用性が向上し、ノードの追加・削除も容易になります。すべてのノード間接続を暗号化するという要件に取り組む際、開発チームは「可用性」と「運用の簡易さ」に重点を置きました。

Redis Enterpriseのような分散型かつ常時稼働（Always-On）のシステムは、多くのミッションクリティカルなアプリケーションを支えています。そのため、最高水準の運用可用性が求められます。Redis Enterpriseを基盤とするRedis Cloudは99.999%の稼働率を提供しており、年間のダウンタイムはわずか数分程度に抑えられます。ノード間クラスタ通信は、クォーラム（制御パス操作）の維持とRedisレプリケーション（データパス操作）の実現において極めて重要です。したがって、ノード間通信の信頼性を常に維持するための高可用性が不可欠となります。

プライベート認証局（CA）とは？

プライベート認証局（Private CA）とは、クラスター固有の証明書発行機関であり、公的に信頼されたCAと同様の役割を果たします。Redisクラスターは独自のプライベートルート証明書を作成し、それを使って各ノード向けのプライベート証明書を発行できます。プライベートCAが発行する証明書は公的には信頼されていませんが、プライベートCA自体はクラスターの外部に公開されることはありません。また、Redisクラスター間で共有されたり、外部のクライアントやサービスと共有されたりすることもありません。プライベートCAによって署名された証明書（エンドエンティティ証明書）は、発行先のノード専用となります。

Redis Enterpriseが採用するプライベートCAは、シームレスな内部自動ローテーション機構を備えています。証明書のローテーションは有効期限が切れる前に自動的に実行されます。さらに、REST API経由でのリクエストによる手動ローテーションにも対応しており、アプリケーションチーム、データベースチーム、セキュリティチームによる監視のためのアラート機能も提供されます。プライベートCAを利用することで、証明書ローテーションにおける外部CAへの依存がなくなり、潜在的な障害点を排除し、クラスター全体の可用性を向上させることができます。

Redis Enterpriseはこのように、プライベート認証局（CA）を使用してノード間暗号化に必要な証明書を管理しています。しかし、顧客からは一般的に以下のような懸念が寄せられます。

顧客の主な懸念事項：

1. 当社の環境では自己署名証明書やプライベートCAの使用が禁止されている。
2. プライベートCAは公的に信頼されていないため、外部通信の信頼確立には使えない。
3. プライベートCAは侵害に対する保護が不十分なことが多い。

最初の懸念は、実はセキュリティ上の問題ではなく、コンプライアンス要件に関わるものです。多くの組織では、自己署名証明書が最適な選択肢となる正当なユースケースを考慮せず、自己署名証明書を全面的に禁止する包括的なポリシーを策定しています。この要件は多くの場面では理にかなっていますが、すべての場合に当てはまるわけではなく、ポリシーが合致しないケースに対して例外的な承認を得るための煩雑なプロセスを生んでしまうこともあります。その一例がRedis Enterpriseのノード間暗号化です。この特定のユースケースにおいて、プライベートCAは明確な目的を持って機能します。

まず、自己署名証明書（Self-Signed Certificate）の定義を確認しましょう。自己署名証明書とは、公的に信頼された第三者CAによって署名されていない証明書のことです。この種の証明書は、その証明書が発行されるWebサイトやアプリケーションを管理する組織自身が作成・発行・署名します。自己署名証明書は無料で発行でき、信頼された第三者CAが発行する証明書と同じ暗号方式を使用できます。

ここで疑問が浮かぶかもしれません。「自己署名証明書の使用が許可されていない場合、代わりの選択肢は何か？」典型的な代替案は、信頼された第三者CAが発行した証明書を使用することです。組織はさまざまな信頼できる第三者CAから証明書を購入し、自社のWebサイトやアプリケーションに展開できます。セキュリティの観点から言えば、信頼された第三者CAが発行した証明書は自己署名証明書と本質的に変わりません。

次に問うべき質問は、「では、自己署名証明書と信頼された第三者CAが発行した証明書の違いは何か？」ということです。両者とも同じ暗号方式をサポートし、ルート証明書、中間証明書、リーフ証明書で構成され、必要に応じて失効させることも可能です。唯一の違いは機能面、すなわち信頼（Trust）の有無です。信頼された第三者CAは、互いに関係のない2つのエンティティ間で信頼関係を確立できる証明書を発行できます。

では、信頼が必要となるのはどのような場面でしょうか。信頼は、互いに関係のない2つのエンティティが通信を行う際に必要となります。分かりやすい例が、WebブラウザとWebアプリケーション間の通信です。第三者の信頼されたCAが発行した証明書を使用すれば、通信の暗号化だけでなく、Webブラウザに対してそのWebアプリケーションが提示通りの存在であることを証明できます。その結果、ブラウザはユーザーに対して「このWebアプリケーションを信頼して通信を続けるかどうか」を確認する警告を表示します。

信頼が不要な場合はいつか？それは、相互に関連する2つのエンティティが通信する場合です。Redis Enterpriseのノード間暗号化は、まさにこのタイプの通信の好例です。Redis Enterpriseは1つのクラスターで構成され、1つのクラスターには複数のノードを含めることができます。さらに、1つのノード上に単一または複数のデータベースを配置することも可能です。各ノードはすべて同じクラスターに属しているため、信頼を確立するために第三者機関は不要です。各ノードは、同じクラスターに属する他のすべてのノードをすでに信頼しているからです。

Redis Enterpriseによる解決策：

Redis Enterpriseは、プライベートCAが生成した証明書をクラスター内部でのみ使用することで、こうしたコンプライアンスおよびセキュリティ上の懸念を解消しています。各ノードは同一クラスター内の他のすべてのノードから既知かつ信頼済みであるため、Redisクラスター内部の信頼確立において、信頼された第三者CAを導入するメリットは一切なく、必要もないのです。