Подключение к учетной записи службы хранилища Azure

  • 10 мин

Итак, вы добавили в приложение все нужные клиентские библиотеки и теперь можете подключаться к учетной записи хранения Azure.

Для работы с данными в учетной записи хранения вашему приложению потребуется два фрагмента данных:

  • Ключ доступа
  • Конечная точка REST API

Ключи доступа безопасности

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

An illustration showing an application connected to two different storage accounts in the cloud. Each storage account is accessible with a unique key.

Конечная точка REST API

Помимо доступа к ключам для проверки подлинности в учетных записях хранения, приложение должно знать конечные точки службы хранилища для выдачи запросов REST.

Конечная точка REST состоит из имени вашей учетной записи хранения, типа данных и известного домена. Например:

Тип данных Пример конечной точки
BLOB-объекты https://[name].blob.core.windows.net/
Очереди https://[name].queue.core.windows.net/
Таблицу https://[name].table.core.windows.net/
Files https://[name].file.core.windows.net/

Если у вас есть личный домен, привязанный к Azure, вы также можете создать личный URL-адрес домена для конечной точки.

Строки подключения

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

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

DefaultEndpointsProtocol=https;AccountName={your-storage};
   AccountKey={your-access-key};
   EndpointSuffix=core.windows.net

Безопасность

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

Как правило, сведения о подключении к учетной записи хранения хранятся в переменной среды, базе данных или файле конфигурации.

Важно!

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

Каждая учетная запись хранения имеет два ключа доступа. Это позволяет периодически поворачивать ключи (повторно создаваться) в рамках рекомендаций по обеспечению безопасности учетной записи хранения. Это можно сделать из портал Azure или средства командной строки Azure CLI или PowerShell.

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

  1. Обновите строка подключения в коде приложения, чтобы ссылаться на дополнительный ключ доступа учетной записи хранения.
  2. Повторно создайте первичный ключ доступа учетной записи хранения с помощью средства портал Azure или командной строки.
  3. Обновите строки подключения в коде, чтобы они ссылались на новый основной ключ доступа.
  4. Повторите процедуру, чтобы повторно создать вторичный ключ доступа.

Совет

Мы настоятельно рекомендуем периодически поворачивать ключи доступа, чтобы гарантировать, что они остаются закрытыми, как и изменение паролей. Если вы используете ключ в серверном приложении, вы можете использовать Azure Key Vault для хранения ключа доступа. Хранилища ключей включают поддержку для синхронизации напрямую с учетной записью хранения и для периодической автоматической замены ключей. Использование Key Vault обеспечивает дополнительный уровень безопасности, поэтому вашему приложению никогда не придется работать напрямую с ключом доступа.

Подписанные URL-адреса (SAS)

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

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