Учетные записи хранения и надежность

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

• BLOB-объекты
• общих папок;
• очередей;
• Таблицы
• Диски

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

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

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

• Избыточность хранилища Azure
• Аварийное восстановление и отработка отказа учетной записи хранения

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

Рекомендации по проектированию

К учетным записям хранения Azure применяются следующие рекомендации по проектированию:

• Учетные записи хранения общего назначения версии 1 обеспечивают доступ ко всем службам хранилища Azure, но не предоставляют новейших возможностей или низких цен за ГБ. В большинстве случаев рекомендуется использовать учетные записи хранения общего назначения версии 2. Ниже приводятся причины использования учетных записей версии 1:

  • Для приложений требуется классическая модель развертывания.
  • В приложениях выполняется большое число транзакций или используется значительная пропускная способность георепликации, но для них не требуется большая емкость.
  • Требуется использовать REST API службы хранилища, выпущенный до 14 февраля 2014 г., или клиентскую библиотеку с версией, предшествующей 4.x. Приложение невозможно обновить.

Дополнительные сведения см. в статье Общие сведения об учетной записи хранения.

• Имя учетной записи хранения должно содержать от 3 до 24 символов и состоять только из цифр и строчных букв.
• Текущие спецификации SLA см. на странице Соглашение об уровне обслуживания для учетных записей хранения.
• Прочтите статью Избыточность хранилища Azure, чтобы определить, какой вариант избыточности лучше подходит для конкретного сценария.
• Имена учетных записей хранения должны быть уникальными в Azure. Две учетные записи хранения не могут иметь одно имя.

Контрольный список

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

• Включите обратимое удаление для данных BLOB-объектов.
• Используйте идентификатор Microsoft Entra для авторизации доступа к данным BLOB-объектов.
• Учитывайте принцип минимальных привилегий при назначении разрешений субъекту безопасности Microsoft Entra с помощью Azure RBAC.
• Для доступа к данным BLOB-объектов и очередей используйте управляемые удостоверения.
• Для хранения критически важных для бизнеса данных используйте управление версиями BLOB-объектов или неизменяемые BLOB-объекты.
• Ограничьте доступ в Интернет по умолчанию для учетных записей хранения.
• Включение правила брандмауэра.
• Разрешайте сетевой доступ только из конкретных сетей.
• Разрешите доверенным службам Майкрософт доступ к учетной записи хранения.
• Включите параметр Требуется безопасное перемещение для всех учетных записей хранения.
• Ограничьте использование маркеров подписанных URL-адресов (SAS) только подключениями по протоколу HTTPS.
• Не используйте и заблокируйте авторизацию с общим ключом для доступа к учетным записям хранения.
• Периодически обновляйте ключи для учетной записи.
• Создайте план отзыва и используйте его для любого SAS, выданного клиентам.
• Используйте истекающие в ближайшее время сроки действия для нерегламентированного SAS, SAS для службы или SAS для учетной записи.

Рекомендации по настройке

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

Рекомендация	Описание
Включите обратимое удаление для данных BLOB-объектов.	Обратимое удаление для BLOB-объектов службы хранилища Azure позволяет восстанавливать данные BLOB-объектов после их удаления.
Используйте идентификатор Microsoft Entra для авторизации доступа к данным BLOB-объектов.	идентификатор Microsoft Entra обеспечивает более высокий уровень безопасности и простоту использования по сравнению с общим ключом для авторизации запросов к хранилищу BLOB-объектов. Рекомендуется по возможности использовать Microsoft Entra авторизацию с приложениями больших двоичных объектов и очередей, чтобы свести к минимуму потенциальные уязвимости системы безопасности, присущие общему ключу. Дополнительные сведения см. в статье Авторизация доступа к BLOB-объектам и очередям Azure с помощью идентификатора Microsoft Entra.
Учитывайте принцип минимальных привилегий при назначении разрешений субъекту безопасности Microsoft Entra с помощью Azure RBAC.	При назначении роли пользователю, группе или приложению предоставьте этому субъекту безопасности только разрешения, необходимые для выполнения задач. Ограничение доступа к ресурсам позволяет предотвратить и непреднамеренное, и злонамеренное неправильное использование данных.
Для доступа к данным BLOB-объектов и очередей используйте управляемые удостоверения.	Хранилище BLOB-объектов и очередей Azure поддерживают проверку подлинности Microsoft Entra с помощью управляемых удостоверений для ресурсов Azure. Управляемые удостоверения для ресурсов Azure могут авторизовать доступ к данным больших двоичных объектов и очередей с помощью Microsoft Entra учетных данных из приложений, работающих на виртуальных машинах Azure, приложений-функций, масштабируемых наборов виртуальных машин и других служб. Используя управляемые удостоверения для ресурсов Azure вместе с проверкой подлинности Microsoft Entra, вы можете избежать хранения учетных данных в приложениях, работающих в облаке, и проблем с субъектами-службами с истекающим сроком действия. Дополнительные сведения см. в статье Авторизация доступа к данным BLOB-объектов и очередей с помощью управляемых удостоверений для ресурсов Azure.
Для хранения критически важных для бизнеса данных используйте управление версиями BLOB-объектов или неизменяемые BLOB-объекты.	Рассмотрите возможность использования управления версиями BLOB-объектов для сохранения предыдущих версий объекта или используйте юридические удержания и политики хранения на основе времени для хранения данных BLOB-объектов в состоянии WORM (однократная запись и многократное считывание). Неизменяемые BLOB-объекты можно считывать, но нельзя изменять или удалять в течение периода хранения. Дополнительные сведения см. в статье Хранение критически важных для бизнеса данных BLOB-объектов с помощью неизменяемого хранилища.
Ограничьте доступ в Интернет по умолчанию для учетных записей хранения.	По умолчанию сетевой доступ к учетным записям хранения не ограничен и открыт для всего трафика, поступающего из Интернета. Доступ к учетным записям хранения должен предоставляться конкретным виртуальным сетям Azure, если это возможно, либо при доступе следует использовать частные конечные точки, чтобы разрешить клиентам в виртуальной сети (VNet) безопасно получать доступ к данным через Приватный канал. Дополнительные сведения см. в статье Использование частных конечных точек для службы хранилища Azure. Для учетных записей хранения, которые должны быть доступны через Интернет, могут быть сделаны исключения.
Включение правила брандмауэра.	Настройте правила брандмауэра для ограничения доступа к учетной записи хранения только для запросов, исходящих из указанных IP-адресов, диапазонов IP-адресов или из списка подсетей в виртуальной сети Azure (VNet). Дополнительные сведения см. в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей.
Разрешайте сетевой доступ только из конкретных сетей.	Ограничение сетевого доступа к сетям, в которых размещаются клиенты, требующие доступа, уменьшает вероятность сетевых атак на ваши ресурсы. Для ограничения сетевого доступа можно использовать встроенные функции брандмауэра и виртуальных сетей или частные конечные точки.
Разрешите доверенным службам Майкрософт доступ к учетной записи хранения.	При включении правил брандмауэра для учетной записи хранения по умолчанию блокируются входящие запросы данных, за исключением запросов от служб, работающих внутри виртуальной сети Azure, и запросов, поступающих с разрешенных общедоступных IP-адресов. В число блокируемых запросов входят запросы от других служб Azure, портала Azure, служб метрик и ведения журналов и т. д. Можно разрешить запросы от других служб Azure, добавив исключение, чтобы предоставить доверенным службам Microsoft доступ к учетной записи хранения. Дополнительные сведения о добавлении исключений для доверенных служб Майкрософт см. в статье Настройка брандмауэров службы хранилища Azure и виртуальных сетей.
Включите параметр Требуется безопасное перемещение для всех учетных записей хранения.	Если включен параметр Требуется безопасное перемещение, все запросы к учетной записи хранения должны выполняться с использованием защищенных подключений. Все запросы, выполненные по протоколу HTTP, завершатся ошибкой. Дополнительные сведения см. в статье Требование безопасной передачи данных в службе хранилища Azure.
Ограничьте использование маркеров подписанных URL-адресов (SAS) только подключениями по протоколу HTTPS.	Требование о применении протокола HTTPS, когда клиент использует маркер SAS для доступа к данным BLOB-объектов, снижает риск перехвата. Дополнительные сведения см. в статье Предоставление ограниченного доступа к ресурсам службы хранилища Azure с помощью подписанных URL-адресов (SAS).
Не используйте и заблокируйте авторизацию с общим ключом для доступа к учетным записям хранения.	Рекомендуется использовать идентификатор Microsoft Entra для авторизации запросов к службе хранилища Azure и предотвращения авторизации по общему ключу. В сценариях, требующих авторизации с помощью общего ключа, всегда рекомендуется использовать маркеры SAS, а не распространение общего ключа.
Периодически обновляйте ключи для учетной записи.	Периодическое изменение ключей учетной записи снижает риск раскрытия данных злоумышленникам.
Создайте план отзыва и используйте его для любого SAS, выданного клиентам.	Если SAS скомпрометирован, необходимо немедленно отозвать его. Чтобы отменить SAS для делегирования пользователей, отмените ключ для делегирования пользователей. Это позволит быстро аннулировать все подписи, связанные с этим ключом. Чтобы отозвать SAS службы, связанный с хранимой политикой доступа, можно удалить хранимую политику доступа, переименовать политику или изменить время окончания ее срока действия на дату в прошлом.
Используйте истекающие в ближайшее время сроки действия для нерегламентированного SAS, SAS для службы или SAS для учетной записи.	Если SAS скомпрометирован, он будет действителен только в течение короткого времени. Это особенно важно в случаях, когда нельзя ссылаться на хранимую политику доступа. Небольшой срок также позволяет ограничить объем данных, который может быть записан в большой двоичный объект, путем ограничения времени на отправку этих данных. Клиенты должны обновлять SAS задолго до окончания его срока действия, чтобы оставить время для повторных попыток в случае недоступности службы, предоставляющей SAS.

Следующий шаг

Учетные записи хранения и безопасность