Модель безопасности для управляемой службы кэша Azure

Статья
11/09/2015

Важно!

Корпорация Майкрософт рекомендует всем новым разработкам использовать кэш Redis для Azure. Текущую документацию и рекомендации по выбору предложения кэша Azure см. в статье о том, какое предложение кэша Azure подходит для меня?

управляемая служба кэша позволяет управлять доступом к кэшу, требуя от клиентских приложений проверки подлинности в кэше с помощью ключей доступа. управляемая служба кэша также обеспечивает возможность безопасного обмена данными между клиентским приложением и кэшем. В данной теме представлены общие сведения об управлении доступом с использованием ключей доступа и о защите связи в вашем кэше.

В этом разделе

Управление доступом с использованием ключей доступа
- Практическое руководство. Последовательное обновление
Обеспечение безопасности соединений между клиентами кэша и кэшем

Управление доступом с использованием ключей доступа

Для того, чтобы гарантировать, что только надлежащие клиентские приложения могут получить доступ к вашему кэшу, всем клиентам необходимо предоставить кэшу ключ доступа.

Когда вы создаете кэш, используя портал управления, он предварительно сконфигурирован с двумя ключами доступа: первичный ключ доступа и вторичный ключ доступа. Вы можете извлечь их, щелкнув Управление ключами либо на вкладке Начало работы для кэша, либо в панели мониторинга кэша.

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 добавлены пакетом кэша NuGet, используемым для настройки клиентов кэша. Дополнительные сведения см. в разделе "Настройка клиента кэша" с помощью пакета кэширования NuGet.

Также предоставляется вторичный ключ доступа, чтобы вы могли обновлять ключи, используя последовательное обновление, благодаря которому ваши приложения не будут простаивать из-за замены ключей.

Практическое руководство. Последовательное обновление

Для сценариев, в которых вам необходимо повторно создать первичный ключ доступа, например, чтобы соответствовать корпоративной политике, или если ключ доступа был скомпрометирован, вы можете выполнить следующие шаги.

Обновите конфигурацию клиентских приложений вашего кэша так, чтобы они использовали вторичный ключ доступа.
В диалоговом окне Управление ключами доступа в портале управления щелкните кнопку Создать повторно для первичного ключа доступа.
Обновите конфигурацию клиентских приложений вашего кэша так, чтобы они использовали новый повторно созданный ключ доступа.

Повторно создайте дополнительный ключ доступа.

Обеспечение безопасности соединений между клиентами кэша и кэшем

управляемая служба кэша обеспечивает возможность безопасного взаимодействия между клиентским приложением и кэшем. Для этого установите sslEnabled = true в элементе securityProperties в разделе dataCacheClients файла web.config или app.config вашего приложения. Это обеспечит прохождение всех соединений между клиентом и кэшем через TLS.

<securityProperties mode="Message" sslEnabled="true">
  <messageSecurity authorizationInfo="[Authentication Key]" />
</securityProperties>

По умолчанию sslEnabled задано значение false, а если sslEnabled атрибут не указан, используется значение false.

Обмен данными между клиентами и кэшами, размещенными в одном регионе Azure, уже защищен. Если кэш размещен в том же регионе Azure, что и клиентское приложение, рекомендуется задать значение sslEnabledfalse. Так как при использовании SSL возникают некоторые издержки, установка sslEnabledзначения true , если клиенты кэша и кэша находятся в одном регионе, неоправданно ухудшают производительность кэша.

Если невозможно использовать как кэш, так и клиент кэша в одном регионе Azure, приложение может получить преимущество зашифрованного обмена данными, установив значение sslEnabledtrue. Обратите внимание на то, что для оптимальной производительности (не только в отношении настройки sslEnabled) необходимо разместить кэш в той же области, что и клиентское приложение.

См. также:

Справочник

Настройка клиента кэша с помощью пакета NuGet для Caching

Другие ресурсы

Функции управляемой службы кэша Azure

Поделиться через