Рекомендации по защите мобильных приложений и веб-приложений PaaS с помощью службы хранилища Azure

Статья
09/29/2024

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

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

Службы хранилища Azure включают хранилище BLOB-объектов, а также хранилища таблиц, очередей и файлов. Дополнительные сведения см. в статье Introduction to Microsoft Azure Storage (Введение в службу хранилища Microsoft Azure).

В этой статье рассматриваются следующие рекомендации:

Подписанные URL-адреса (SAS)
Управление доступом на основе ролей в Azure (Azure RBAC)
шифрование на стороне клиента для важных данных;
Шифрование службы хранилища

Использование подписанного URL-адреса вместо ключа учетной записи хранения

Управление доступом является критически важным. Чтобы помочь вам контролировать доступ к службе хранилища Azure, при создании учетной записи хранения Azure создаст два 512-разрядных ключа доступа (SAK). Уровень избыточности ключа позволяет избежать прерывания службы во время процедуры смены ключей.

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

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

Период действия SAS, включая время начала и окончания срока действия.
Разрешения, предоставляемые с помощью SAS. Например, SAS для большого двоичного объекта может предоставить разрешения на чтение и запись для него, но не разрешение на удаление.
Дополнительный IP-адрес или диапазон IP-адресов, по которым служба хранилища Azure будет принимать SAS. Например, можно указать диапазон IP-адресов, принадлежащих организации. Таким образом обеспечивается еще одна мера безопасности для SAS.
Протокол, по которому служба хранилища Azure будет принимать SAS. С помощью этого необязательного параметра можно ограничить доступ к клиентам, использующим протокол HTTPS.

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

Дополнительные сведения о подписанных URL-адресах см. в статье Использование подписанных URL-адресов (SAS).

Использование управления доступом на основе ролей в Azure

Еще одним способом является использование управления доступом на основе ролей в Azure (Azure RBAC). Используя Azure RBAC, вы сосредотачиваетесь на предоставлении сотрудникам именно тех разрешений, в которых они нуждаются, исходя из принципов безопасности, выполнения должностных обязанностей и минимальных привилегий. Слишком большое число разрешений делает учетную запись уязвимой для злоумышленников. Недостаточное число разрешений мешает эффективной работе сотрудников. Azure RBAC помогает решить эту задачу, обеспечивая точное управление доступом для Azure. Управление доступом является обязательным для организаций, которые хотят применять политики безопасности для доступа к данным.

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

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

Дополнительные сведения об Azure RBAC

Использование шифрования на стороне клиента для важных данных

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

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

Шифрование на стороне клиента встроено в библиотеки хранилищ Java и .NET. Дополнительные сведения о шифровании данных в клиентских приложениях и о создании собственных ключей шифрования и управлении ими см. в статье Шифрование на стороне клиента для службы хранилища Microsoft Azure.

Включение функции "Шифрование службы хранилища" для неактивных данных

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

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

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

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