Рекомендации по мониторингу Хранилища BLOB-объектов
В этой статье рассматриваются типичные сценарии мониторинга Хранилища BLOB-объектов, а также приведены рекомендации по их реализации.
Определение учетных записей хранения с низким или нулевым уровнем использования
Аналитика для службы хранилища — это панель мониторинга на основе метрик и журналов службы хранилища Azure. Аналитику для службы хранилища можно использовать для проверки объема транзакций и используемой емкости всех учетных записей. Эта информация поможет вам решить, какие учетные записи можно снять с учета. Сведения о настройке аналитики для службы хранилища см. в статье Мониторинг службы хранилища с помощью аналитики хранилища Azure Monitor.
Анализ объема транзакций
В представлении аналитики хранилища в Azure Monitorотсортируйте свои учетные записи в возрастающем порядке по столбцу Транзакции. На изображении ниже показана учетная запись с низким объемом транзакций за указанный период.
Чтобы узнать больше об определенных транзакциях, щелкните ссылку соответствующей учетной записи. В этом примере большинство запросов совершаются к службе Хранилища BLOB-объектов.
Чтобы определить, какие виды запросов совершаются, детализируйте данные на диаграмме транзакций по имени API.
В этом примере все запросы представляют собой операции получения списка или запросы сведений о свойствах учетной записи. Транзакций чтения и записи нет. Это может натолкнуть на мысль, что учетная запись не используется в существенным образом.
Анализ используемой емкости
На вкладке Емкость в представлении аналитики хранилища в Azure Monitor отсортируйте учетные записи в порядке возрастания по столбцу Используемая емкость учетной записи. На изображении ниже показана учетная запись с меньшей емкостью, чем у других учетных записей.
Чтобы проверить большие двоичные объекты, связанные с используемой емкостью, используйте Обозреватель службы хранилища. Для большого количества BLOB-объектов можно создать отчет с помощью политики инвентаризации BLOB-объектов.
Мониторинг использования контейнера
Если данные клиентов секционированы по контейнерам, вы можете отслеживать, какую емкость использует каждый клиент. Для инвентаризации BLOB-объектов с данными о размере можно использовать функцию инвентаризации BLOB-объектов службы хранилища Azure. Затем можно агрегировать размер и количество на уровне контейнера. Пример см. в статье Расчет числа BLOB-объектов и общего размера для контейнера с помощью инвентаризации хранилища Azure.
Вы также можете оценить трафик на уровне контейнера путем запроса к журналам. Дополнительные сведения о составлении запросов Log Analytics см. здесь. Дополнительные сведения о схеме журналов хранилища см. в справочнике по данным мониторинга Хранилища BLOB-объектов Azure.
Ниже приведен запрос для получения числа транзакций чтения и числа байтов, считанных в каждом контейнере.
StorageBlobLogs
| where OperationName == "GetBlob"
| extend ContainerName = split(parse_url(Uri).Path, "/")[1]
| summarize ReadSize = sum(ResponseBodySize), ReadCount = count() by tostring(ContainerName)
Ниже приведен аналогичный запрос для получения сведений об операциях записи.
StorageBlobLogs
| where OperationName == "PutBlob" or
OperationName == "PutBlock" or
OperationName == "PutBlockList" or
OperationName == "AppendBlock" or
OperationName == "SnapshotBlob" or
OperationName == "CopyBlob" or
OperationName == "SetBlobTier"
| extend ContainerName = split(parse_url(Uri).Path, "/")[1]
| summarize WriteSize = sum(RequestBodySize), WriteCount = count() by tostring(ContainerName)
Запрос выше использует имена нескольких операций, так как запись может быть реализована разными способами. Дополнительные сведения о том, какие операции считаются операциями чтения и записи, см. в статьях о ценах на Хранилище BLOB-объектов Azure и Azure Data Lake Storage.
Аудит действий учетной записи
Во многих случаях для обеспечения безопасности и соответствия требованиям требуется аудит действий учетных записей хранения. Операции с учетными записями хранения можно разделить на две категории: уровень управления и плоскость данных.
Операция уровня управления представляет собой любой запрос Azure Resource Manager на создание учетной записи хранения или обновление свойства существующей учетной записи хранения. Дополнительные сведения см. в статье об Azure Resource Manager.
Операция в плоскости данных — это операция с данными в учетной записи хранения, полученная в результате запроса к конечной точке службы хранилища. Например, операция в плоскости данных выполняется при отправке большого двоичного объекта в учетную запись хранения или при скачивании из нее такого объекта. Дополнительные сведения см. в статье об API службы хранилища Azure.
В этом разделе объясняется, показано, как ответить на вопросы "когда", "кто", "что" и "как" об операциях уровня управления и плоскости данных.
Аудит операций уровня управления
Операции Resource Manager фиксируются в журнале действий Azure. Чтобы просмотреть журнал действий, откройте учетную запись хранения на портале Azure, а затем выберите Журнал действий.
Откройте любую запись журнала, чтобы просмотреть код JSON, описывающий действие. В следующем примере JSON показаны сведения "когда", "что" и "как" об операции плоскости управления:
Доступность ответов на вопрос "кто" зависит от способа проверки подлинности, который использовался для операции на уровне управления. Если авторизация была выполнена субъектом безопасности Microsoft Entra, идентификатор объекта этого субъекта безопасности также будет отображаться в выходных данных JSON (например: "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Поскольку другие сведения, связанные с удостоверениями, такие как адрес электронной почты или имя, отображаются не всегда, идентификатор объекта всегда лучше всего уникальным образом идентифицирует субъекта безопасности.
Понятное имя этого субъекта безопасности можно найти, принимая значение идентификатора объекта и выполняя поиск субъекта безопасности на странице идентификатора Microsoft Entra ID портал Azure. На следующем снимке экрана показан результат поиска в идентификаторе Microsoft Entra.
Аудит операций в плоскости данных
Операции в плоскости данных фиксируются в журналах ресурсов Azure для службы хранилища. Вы можете настроить параметр диагностики для экспорта журналов в рабочую область Log Analytics для использования встроенных средств работы с запросами.
Ниже приведен запрос Log Analytics, который получает сведения "когда", "кто", "что" и "как" в списке записей журнала.
StorageBlobLogs
| where TimeGenerated > ago(3d)
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Для аудита сведений категории "когда" в поле TimeGenerated показано время создания записи журнала.
Для аудита сведений категории "что" в поле Uri указано, какой именно объект был изменен или прочитан.
Для аудита сведений категории "как" в поле OperationName показано, какая операция была выполнена.
Совет
Например, если вы подозреваете, что большой двоичный объект или контейнер был удален по ошибке, добавьте where предложение, которое возвращает только записи журнала, в которых OperationName задано значение Delete BLOB-объект или Delete Container.
Для аудита сведений категории "что" в поле AuthenticationType показано, какой тип проверки подлинности использовался для выполнения запроса. Это поле может показать любой из типов проверки подлинности, которые служба хранилища Azure поддерживает, включая использование ключа учетной записи, маркера SAS или проверки подлинности Microsoft Entra.
Если запрос авторизован с помощью идентификатора Microsoft Entra, можно использовать RequestObjectId поле для идентификации "кто". Общий ключ и проверка подлинности SAS не позволяют проводить аудит отдельных удостоверений. В таких случаях callerIPAddress userAgentHeader поля могут помочь определить источник операции. Если маркер SAS использовался для авторизации операции, можно определить этот маркер и, если вы сопоставили маркеры с получателями маркеров в конце, можно определить, какой пользователь, организация или приложение выполнили операцию. См. сведения об идентификации маркера SAS, используемого для авторизации запроса.
Определение субъекта безопасности, который использовался для авторизации запроса
Если запрос прошел проверку подлинности с помощью идентификатора Microsoft Entra, RequesterObjectId поле предоставляет наиболее надежный способ идентификации субъекта безопасности. Вы можете найти понятное имя этого субъекта безопасности, выполнив значение RequesterObjectId поля и выполнив поиск субъекта безопасности на странице идентификатора Microsoft Entra портал Azure. На следующем снимке экрана показан результат поиска в идентификаторе Microsoft Entra.
В некоторых случаях в журналах может отображаться имя субъекта-пользователя или UPN. Например, если субъект безопасности является пользователем Microsoft Entra, имя участника-пользователя, скорее всего, появится. Для других типов субъектов безопасности, таких как назначенные пользователем управляемые удостоверения, или в некоторых сценариях, таких как проверка подлинности клиента Microsoft Entra, имя участника-пользователя не будет отображаться в журналах.
В этом запросе отображаются все операции чтения, выполняемые субъектами безопасности OAuth.
StorageBlobLogs
| where TimeGenerated > ago(3d)
and OperationName == "GetBlob"
and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Общий ключ и проверка подлинности SAS не позволяют проводить аудит отдельных удостоверений. Поэтому, если вы хотите улучшить возможность аудита на основе удостоверений, рекомендуется перейти на идентификатор Microsoft Entra и запретить проверку подлинности SAS и общий ключ. Сведения о том, как запретить проверку подлинности на основе общего ключа и SAS, см. в статье о запрете авторизации с использованием общего ключа для учетной записи хранения Azure. Сведения о начале работы с идентификатором Microsoft Entra см. в статье "Авторизация доступа к BLOB-объектам с помощью идентификатора Microsoft Entra".
Определение маркера SAS, который использовался для авторизации запроса
Вы можете запрашивать операции, авторизованные с помощью маркера SAS. Например, такой запрос возвращает все операции записи, авторизованные с помощью маркера SAS.
StorageBlobLogs
| where TimeGenerated > ago(3d)
and OperationName == "PutBlob"
and AuthenticationType == "SAS"
| project TimeGenerated, AuthenticationType, AuthenticationHash, OperationName, Uri
По соображениям безопасности сами маркеры SAS в журналах не отображаются. Однако хэш SHA-256 сигнатуры маркера SAS появится в AuthenticationHash поле, возвращаемом этим запросом.
Если вы распространили несколько маркеров SAS и хотите знать, какие маркеры SAS используются, необходимо преобразовать часть подписи каждого из маркеров SAS в хэш SHA-256, а затем сравнить его с хэш-значением, которое отображается в журналах.
Для начала расшифруйте каждую строку маркера SAS. В следующем примере декодирует часть подписи строки маркера SAS с помощью PowerShell.
[uri]::UnescapeDataString("<SAS signature here>")
Для преобразования декодированного сигнатуры в SHA-256 можно использовать любое средство или пакет SDK. Например, в системе Linux можно использовать следующую команду:
echo -n "<Decoded SAS signature>" | python3 -c "import sys; from urllib.parse import unquote; print(unquote(sys.stdin.read()), end='');" | sha256sum
Другой способ преобразования декодированного сигнатуры — передать декодированную строку в функцию hash_sha256() в рамках запроса при использовании Azure Data Explorer.
Маркеры SAS не содержат идентифицирующих сведений. Один из способов отслеживания действий пользователей и организаций — сопоставление пользователей или организаций с разными хэшами маркеров SAS.
Оптимизация затрат для нечастых запросов
Для выполнения расширенных запросов журналы можно экспортировать в Log Analytics. При большом объеме транзакций в учетной записи хранения стоимость использования журналов с Log Analytics может быть высокой. Дополнительные сведения см. на странице цен на Log Analytics. Если запрашивать журналы планируется нечасто (например, для аудита соответствия), вы можете сократить общую стоимость, экспортировав их в учетную запись хранения, а затем используя бессерверное решение для запросов на основе данных журналов, например Azure Synapse.
С помощью Azure Synapse можно создать бессерверный пул SQL для запроса данных журналов по мере необходимости. Это позволяет значительно снизить затраты.
Экспортируйте журналы в учетную запись хранения. Дополнительные сведения см. в разделе Запись параметра диагностики.
Создайте и настройте рабочую область Synapse. Дополнительные сведения см. в кратком руководстве Создание рабочей области Synapse.
Запрашивайте журналы. Дополнительные сведения см. в статье Запрос файлов JSON с помощью бессерверного пула SQL в Azure Synapse Analytics.
Приведем пример:
select JSON_VALUE(doc, '$.time') AS time, JSON_VALUE(doc, '$.properties.accountName') AS accountName, JSON_VALUE(doc, '$.identity.type') AS identityType, JSON_VALUE(doc, '$.identity.requester.objectId') AS requesterObjectId, JSON_VALUE(doc, '$.operationName') AS operationName, JSON_VALUE(doc, '$.callerIpAddress') AS callerIpAddress, JSON_VALUE(doc, '$.uri') AS uri doc from openrowset( bulk 'https://demo2uswest4log.blob.core.windows.net/insights-logs-storageread/resourceId=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/mytestrp/providers/Microsoft.Storage/storageAccounts/demo2uswest/blobServices/default/y=2021/m=03/d=19/h=*/m=*/PT1H.json', format = 'csv', fieldterminator ='0x0b', fieldquote = '0x0b' ) with (doc nvarchar(max)) as rows order by JSON_VALUE(doc, '$.time') desc