Redis
 Computer >> コンピューター >  >> プログラミング >> Redis

Redis TLS – RedisEnterprise6.2.4のノード間暗号化

Redis Enterprise 6.2.4では、ノード間暗号化が導入されました。 Redis Enterpriseのノード間暗号化の範囲は、以下を含む、ノード間のすべての内部Redisクラスター接続のTLS暗号化を実現することです。

  1. コントロールプレーン接続を強化してCCS(クラスター構成ストア)レプリケーションを暗号化します。
  2. レプリカノードからプライマリノードCCSへのすべての接続。
  3. ノード間のシャードレプリケーションを暗号化するためのデータプレーン接続。
  4. ノード間のシャード接続へのすべてのプロキシ。
Redis TLS – RedisEnterprise6.2.4のノード間暗号化

Redis Enterprise:設計上の考慮事項

Redis Enterpriseは、いくつかの手法を使用してパフォーマンスと可用性を最適化します。 Redisクラスターはシェアードナッシングアーキテクチャを使用しているため、信頼性と可用性が向上し、ノードの追加と削除が簡単になります。すべてのノード間接続を暗号化するという要件に近づくとき、チームは可用性と運用の簡素化に焦点を合わせました。

Redis Enterpriseなどの分散型の常時接続システムは、多くのミッションクリティカルなアプリケーションに電力を供給します。最高水準の運用可用性を満たす必要があります。 RedisEnterpriseを搭載したRedisCloudは、99.999%の可用性を提供します。つまり、1年に数分間しかダウンできません。ノード間クラスター通信は、クォーラムを維持し(制御パス操作)、Redisレプリケーションを有効にする(データパス操作)ために重要です。したがって、ノード間通信の信頼性を常に維持するには、高可用性が不可欠です。

プライベート認証局(CA)とは何ですか?:

プライベート認証局(CA) は、公的に信頼されているCAのように機能するクラスター固有の認証局です。 Redisクラスターは、ノードごとに他のプライベート証明書を発行できる独自のプライベートルート証明書を作成します。プライベートCAによって発行されたプライベート証明書は、公的に信頼されていません。プライベートCAはクラスターの外部に公開されていません。プライベートCAは、Redisクラスター間、または外部クライアントやサービスとは共有されません。プライベートCAによって署名された証明書(エンドエンティティ証明書)は、発行先のノード専用です。

Redis Enterpriseで使用されるプライベートCAは、シームレスな内部自己ローテーションメカニズムを提供します。証明書のローテーションは、有効期限が切れる前に自動的に実行されます。証明書のローテーションは、RESTAPIを介した要求に応じて実行することもできます。アプリケーション、データベース、およびセキュリティチームによる監視のためのアラートも提供されます。プライベートCAは、証明書ローテーションの外部CA可用性への依存を取り除き、潜在的な障害点を取り除き、クラスターの全体的な可用性を向上させます。

Redis Enterpriseは、プライベート認証局(CA)を使用してノード間暗号化に必要な証明書を管理することにより、これを実現します。顧客は通常、プライベートCAの使用に関連して次の主な懸念事項を抱えています。

お客様の懸念:

  1. 私たちの環境では、自己署名証明書やプライベートCAは許可されていません。
  2. プライベートCAは公的に信頼されていないため、外部通信の信頼を確立できません。
  3. プライベートCAは、多くの場合、侵害から適切に保護されていません。

最初の懸念は、実際にはセキュリティの懸念ではありません。これはコンプライアンス要件です。多くの組織は、自己署名証明書が最良の選択肢である有効な使用例を考慮せずに、自己署名証明書を完全に禁止する包括的なポリシーを作成しています。この要件は、すべてではありませんが多くのインスタンスに意味があり、これらの同じ組織は、包括的なポリシーが適合しないインスタンスの除外を許可するための詳細なプロセスを要求するようになりました。 1つの例は、RedisEnterpriseノード間暗号化です。この特定の例では、プライベートCAが特定の目的を果たします。

まず、自己署名証明書を定義しましょう 。自己署名証明書は、公的に信頼されているサードパーティのCAによって署名されていない証明書です。このタイプの証明書は、証明書が発行されるWebサイトまたはアプリケーションを担当する組織によって作成、発行、および署名されます。これらの証明書は、信頼できるサードパーティCAによって発行された証明書と同じ暗号を自由に発行および使用できます。

「組織が自己署名証明書の使用を許可していない場合、代替手段は何ですか?」と自問するかもしれません。一般的な代替手段は、信頼できるサードパーティのCAによって発行された証明書を使用することです。組織は、これらの証明書をさまざまなサードパーティの信頼できるCAから購入してから、その証明書をWebサイトまたはアプリケーションに発行できます。信頼できるサードパーティのCAによって発行された証明書は、セキュリティに関する限り、自己署名証明書と同じです。

次の質問は次のとおりです。自己署名証明書と信頼できるサードパーティのCAによって発行された証明書の間に違いはありますか?各証明書は同じ暗号をサポートします。それぞれ、ルート証明書、中間証明書、およびリーフ証明書で構成されています。それぞれは、必要に応じて期限切れまたは取り消すこともできます。唯一の違いは、自己署名証明書と信頼できるサードパーティCAによって発行された証明書の機能の違いです。その機能は信頼です。信頼できるサードパーティのCAは、2つの無関係なエンティティ間の信頼を確立するために使用できる証明書を発行できます。

いつ信頼が必要ですか?信頼は、2つの無関係なエンティティが通信している場合のソリューションの必須部分です。この良い例は、WebブラウザとWebアプリケーション間の通信です。サードパーティの信頼できるCA発行の証明書を使用すると、暗号化された通信が可能になりますが、WebブラウザはWebアプリケーションが実際に自分自身を提示している人物であることを認識できます。その結果、ユーザーがWebアプリケーションを信頼し、通信を続行したい場合、ブラウザーはユーザーにプロンプ​​トを表示します。

信頼が不要なのはいつですか? 2つの関連するエンティティが通信している場合、信頼はソリューションの必須部分ではありません。 Redis Enterpriseのノード間暗号化は、このタイプの通信の良い例です。 Redis Enterpriseは1つのクラスターで構成され、1つのクラスターに複数のノードを含めることができます。ノード上に単一または複数のデータベースが存在する場合もあります。各ノードは同じクラスターに属しているため、信頼を確立するためにサードパーティは必要ありません。同じクラスターに属しているため、各ノードはすでに他のすべてのノードを信頼しています。

Redisエンタープライズソリューション:

Redis Enterpriseは、プライベートCAで生成された証明書がクラスター内でのみ使用されるため、これらのコンプライアンスとセキュリティの懸念を軽減します。各ノードは同じクラスター内の他のすべてのノードによって認識され、信頼されているため、サードパーティの信頼できるCAは何も追加せず、Redisクラスター内で信頼を確立する必要はありません。


  1. DynomiteデータベースをRedisEnterpriseActive-Activeデータベースに移行する方法

    この記事のパートI「DynomiteデータベースをRedisEnterpriseActive-Activeデータベースに移行する理由」では、DynomiteとRedisEnterpriseのアーキテクチャと機能を比較しました。 Redis Enterpriseが、機能が豊富で管理しやすい方法でRedis Enterpriseを地理的に分散し、同時書き込み間の競合を心配しないようにする方法を示しました。 パートIIでは、DynomiteからRedisEnterpriseに移行するために利用できる移行オプションについて説明します。 以降、Redis Enterpriseの自己管理型オファリング

  2. DynomiteデータベースをRedisEnterpriseActive-Activeデータベースに移行する理由

    2009年の創設以来、RedisOSSには非常に活気のあるオープンソースコミュニティがあります。多くのツールとユーティリティがその周りで開発されており、非分散データストアのピアツーピア地理的分散レイヤーであるDynomiteはその1つです。 Dynomiteは、Netflixのエンジニアのチームによって開発され、オープンソースとしてリリースされました。特定のニーズに対応する優れたソリューションを提供してきましたが、ここ数年は効果的に維持されていません。さらに、Redis OSSの機能、コマンド、データタイプの一部(Pub / SubやStreamsなど)は、DynomiteのRedisOSS