Azure Managed Cache Service のセキュリティ モデル
重要
Microsoft では、すべての新しい開発で Azure Redis Cache を使用することをお勧めします。 Azure Cache オファリングの選択に関する最新のドキュメントとガイダンスについては、「自分に適した Azure Cache オファリング」を参照してください。
Managed Cache Serviceでは、クライアント アプリケーションにアクセス キーを使用してキャッシュに対する認証を要求することで、キャッシュへのアクセスを制御できます。 Managed Cache Serviceは、クライアント アプリケーションとキャッシュ間のチャネル通信をセキュリティで保護する機能も提供します。 このトピックでは、アクセス キーを使用したアクセス制御の概要と、キャッシュとの通信のセキュリティ保護の概要について説明します。
このセクションの内容
アクセス キーを使用したアクセス制御
- 方法: ローリング 更新を実行する
キャッシュ クライアントとキャッシュとの通信のセキュリティ保護
アクセス キーを使用したアクセス制御
意図したクライアント アプリケーションのみがキャッシュにアクセスできるようにするには、すべてのクライアントに対して、キャッシュのアクセス キーの提示を求めます。
管理ポータルを使用してキャッシュを作成すると、プライマリ アクセス キーとセカンダリ アクセス キーの 2 つのアクセス キーが事前に構成されます。 これらのキーを取得するには、キャッシュの [クイック スタート] タブまたはキャッシュ ダッシュボードで [キーの管理] をクリックします。
.jpg "Manage Access Keys for Windows Azure Cache Service")
これらのアクセス キーを使用して、クライアント アプリケーションを構成します。
注意
通常は、プライマリ アクセス キーを使用します。セカンダリ アクセス キーは、プライマリ アクセス キーの再生成時にローリング アップデートを実行するために使用します。 この手順については、「方法: ローリング更新を実行する」セクションで説明します。
クライアント アプリケーションでキャッシュのアクセス キーを指定するには、アプリケーションの web.config ファイルまたは app.config ファイルを開いて、securityProperties セクションの dataCacheClients 要素を見つけます。
<!--<securityProperties mode="Message" sslEnabled="false">
<messageSecurity authorizationInfo="[Authentication Key]" />
</securityProperties>-->
このスニペットのコメントを解除し、[Authentication Key] をプライマリ アクセス キーで置き換えます。 認証キーが正しく構成されていない場合は、クライアントがキャッシュに接続できなくなります。
注意
securityProperties セクションと dataCacheClients セクションは、キャッシュ クライアントを構成するために使用される Cache NuGet パッケージによって追加されます。 詳細については、「キャッシュ NuGet パッケージを使用してキャッシュ クライアントを構成する」を参照してください。
セカンダリ アクセス キーも用意されているのは、ローリング アップデートを使用してキーを更新するときに、キーの変更が原因でアプリケーション側のダウンタイムが発生することを防ぐためです。
方法: ローリング 更新を実行する
プライマリ アクセス キーの再生成が必要になるシナリオとしては、会社のポリシーで再生成が要求されている場合や、アクセス キーが不正使用された場合などがありますが、このようなときに次の手順を実行します。
セカンダリ アクセス キーを使用するようにキャッシュ クライアント アプリケーションの構成を更新します。
管理ポータルの [アクセス キーの管理] ダイアログ ボックスで、プライマリ アクセス キーの [再生成] をクリックします。
新たに再生成されたプライマリ アクセス キーを使用するようにキャッシュ クライアント アプリケーションの構成を更新します。
セカンダリ アクセス キーを再生成します。
キャッシュ クライアントとキャッシュとの通信のセキュリティ保護
Managed Cache Serviceは、クライアント アプリケーションとキャッシュ間の通信をセキュリティで保護する機能を提供します。 このようにするには、アプリケーションの web.config ファイルまたは app.config ファイルの sslEnabled = true セクションにある securityProperties 要素内で dataCacheClients と設定します。 これで、クライアントとキャッシュとの通信はすべて TLS を経由するようになります。
<securityProperties mode="Message" sslEnabled="true">
<messageSecurity authorizationInfo="[Authentication Key]" />
</securityProperties>
既定では false sslEnabledに設定され、属性が sslEnabled 指定されていない場合、使用される値は false です。
同じ Azure リージョンでホストされているクライアントとキャッシュ間の通信は、既にセキュリティで保護されています。 キャッシュがクライアント アプリケーションと同じ Azure リージョンでホストされている場合は、false に設定sslEnabledすることをお勧めします。 SSL を使用するとオーバーヘッドが発生するため、キャッシュ クライアントとキャッシュ クライアントが同じリージョンにある場合に true に設定sslEnabledすると、キャッシュのパフォーマンスが不必要に低下します。
キャッシュとキャッシュ クライアントの両方を同じ Azure リージョンに含めることができなければ、アプリケーションは true に設定sslEnabledすることで暗号化された通信の利点を受け取る可能性があります。 最適なパフォーマンスを得るためには (sslEnabled の設定が関係する場合以外でも)、キャッシュをキャッシュ クライアント アプリケーションと同じリージョンに配置してください。
参照
リファレンス
Caching NuGet パッケージを使用してキャッシュ クライアントを構成する