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

  • 8 мин

Мы рассмотрели, как создать и работать с подписанным URL-адресом (SAS) и преимуществами, которые он может предоставить вашему решению для обеспечения безопасности хранилища.

Важно понимать, что при использовании SAS в приложении могут возникнуть потенциальные риски.

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

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

Просмотрите это видео для получения дополнительных идей о том, как защитить хранилище. Это видео основано на рекомендациях и рекомендациях по безопасности Azure 272.

Рекомендации по управлению рисками

Рассмотрим некоторые рекомендации, которые помогут снизить риски при работе с SAS.

Рекомендация Description
Всегда используйте HTTPS для создания и распространения Если SAS передается по протоколу HTTP и перехватывается, злоумышленник может перехватывать и использовать SAS. Эти атаки злоумышленника в середине могут скомпрометировать конфиденциальные данные или разрешить повреждение данных злоумышленником.
Ссылка на хранимые политики доступа по возможности Хранимые политики доступа предоставляют возможность отзыва разрешений без повторного создания ключей учетной записи хранения Azure. Задайте дату окончания срока действия ключа учетной записи хранения в будущем.
Установка ближайшего срока действия для незапланированного SAS Если SAS скомпрометирован, вы можете устранить атаки, ограничив срок действия SAS коротким временем. Это важно в случаях, когда нельзя ссылаться на хранимую политику доступа. Небольшой срок также позволяет ограничить объем данных, который может быть записан в большой двоичный объект, путем ограничения времени на отправку этих данных.
Требовать автоматическое продление SAS клиентами Требуется, чтобы клиенты обновляли SAS до истечения срока действия. При продлении до начала вы можете разрешить время повторных попыток, если служба, предоставляющая SAS, недоступна.
Тщательно планируйте время начала SAS Если задать время начала для SAS сейчас, то из-за отклонений часов (различия в текущем времени в соответствии с разными компьютерами) могут наблюдаться периодические сбои в течение первых нескольких минут. Как правило, задайте время начала не менее 15 минут в прошлом. Или не устанавливайте определенное время начала, что приводит к тому, что SAS будет действительным немедленно во всех случаях. Те же условия обычно применяются к времени истечения срока действия. По любому запросу можно наблюдать до 15 минут часов. Для клиентов, использующих версию REST API ранее 2012-02-12, максимальная длительность SAS, которая не ссылается на хранимую политику доступа, составляет 1 час. Любые политики, указывающие длительный сбой.
Определение минимальных разрешений доступа для ресурсов Из соображений безопасности рекомендуется предоставить пользователю минимально необходимый набор прав. Если пользователю требуется только доступ для чтения к отдельной сущности, предоставьте доступ на чтение к этой сущности, а не доступ на чтение, запись и удаление для всех сущностей. Эта практика также помогает уменьшить ущерб, если SAS скомпрометирован, так как SAS имеет меньше мощности в руках злоумышленника.
Общие сведения о выставлении счетов за использование, включая SAS Предоставьте ограниченные разрешения для устранения потенциальных действий злоумышленников. Разрешения на чтение и запись могут привести к выставлению счетов. Используйте короткий SAS для уменьшения этой угрозы.
Проверка данных, записанных с помощью SAS Когда клиентское приложение записывает данные в учетную запись хранения Azure, учтите, что с данными могут возникнуть проблемы. Если приложению требуются проверенные или авторизованные данные, проверьте данные после записи, но прежде чем использовать. Такой подход также обеспечивает защиту от поврежденных или вредоносных данных, записываемых в вашу учетную запись как пользователем, который получил подпись правомерно, так и пользователем, использующим подпись после ее утечки.
Не предполагайте, что SAS всегда является правильным выбором В некоторых сценариях риски, связанные с определенной операцией с учетной записью хранения Azure, перевешивают преимущества использования SAS. Для таких операций создавайте службу среднего уровня, которая записывает данные в вашу учетную запись хранения после выполнения проверки, проверки подлинности и аудита на основании бизнес-правил. Кроме того, иногда проще управлять доступом другими способами. Если вы хотите сделать все большие двоичные объекты в контейнере общедоступным для чтения, можно сделать контейнер общедоступным, а не предоставлять SAS каждому клиенту для доступа.
Мониторинг приложений с помощью аналитики служба хранилища Azure Вы можете использовать ведение журнала и метрики для наблюдения за любым всплеском сбоев проверки подлинности. Вы можете увидеть пики из-за сбоя в службе поставщика SAS или на случайное удаление хранимой политики доступа.