Учетные записи Azure Storage

Azure Storage Account — это основной ресурс, предоставляющий доступ к ключевым службам хранения Azure: Blob Storage (объектное хранилище), Azure Files (управляемые общие файловые ресурсы), Queue Storage (очереди сообщений), Table Storage (хранилище пар «ключ–значение» NoSQL) и Azure Data Lake Storage Gen2 (иерархическое пространство имён для аналитики). Одна учётная запись хранения может одновременно размещать все эти службы и предоставляет уникальное пространство имён в Azure — имя учётной записи становится частью URL каждого содержащегося в ней объекта.

Azure предлагает несколько типов учётных записей хранения: Standard общего назначения v2 (GPv2) — рекомендуемый тип для большинства сценариев; поддерживает все службы хранения и варианты избыточности со стандартной производительностью. Premium block blobs — хранилище на основе SSD для сценариев, требующих очень низкой задержки при операциях с Blob Storage. Premium file shares — общие ресурсы Azure Files на основе SSD для рабочих нагрузок с высоким показателем IOPS, например баз данных или домашних каталогов. Premium page blobs — хранилище на SSD для дисков ОС и дисков данных Azure VM (Managed Disks используют его внутренним образом). Для большинства сценариев начните с учётной записи Standard GPv2.

Azure Storage автоматически создаёт копии Ваших данных, чтобы защитить их от отказов оборудования. Доступны четыре варианта избыточности: LRS (Locally Redundant Storage) — три синхронные копии в одном центре обработки данных. ZRS (Zone-Redundant Storage) — три синхронные копии в трёх зонах доступности одного региона. GRS (Geo-Redundant Storage) — LRS в основном регионе и асинхронная репликация во вторичный регион (LRS). GZRS (Geo-Zone-Redundant Storage) — ZRS в основном регионе и асинхронная репликация во вторичный регион. Чем выше избыточность, тем выше долговечность и стоимость.

Выбирайте уровень избыточности с учётом требований к RTO, RPO и бюджету: LRS — самый дешёвый вариант, долговечность 11 девяток, без защиты от отказа центра обработки данных. Используйте его для разработки и тестирования или для данных, которые можно восстановить заново. ZRS — защищает от отказа центра обработки данных и подходит для рабочих данных в одном регионе. GRS/GZRS — защищает от полной недоступности региона Azure; данные асинхронно реплицируются в парный регион. Для критически важных бизнес-данных, которые должны пережить региональную катастрофу, GRS или GZRS являются подходящим выбором, несмотря на дополнительные затраты.

Azure Storage предлагает два уровня производительности: Standard — на основе жёстких дисков (HDD), подходит для большинства рабочих нагрузок при меньшей стоимости за GB. Premium — на основе твердотельных накопителей (SSD), предназначен для сценариев, чувствительных к задержке и требующих операций ввода-вывода с задержкой в единицы миллисекунд. Для хранилища Standard плата рассчитывается за каждый сохранённый GB; Premium стоит дороже за GB, но обеспечивает стабильную и предсказуемую производительность. Для веб-ресурсов, резервных копий, журналов и архивирования подходит Standard. Для VM с базами данных, интенсивно использующими ввод-вывод, или файловых ресурсов, к которым обращаются пользователи настольных компьютеров, лучше выбрать Premium.

Имена учётных записей хранения должны быть глобально уникальными во всём Azure (поскольку они входят в общедоступное имя DNS, например mystorageacct.blob.core.windows.net). Имена должны содержать от 3 до 24 символов и состоять только из строчных букв и цифр — дефисы, символы подчёркивания и прописные буквы не допускаются. Поскольку имена должны быть глобально уникальными, распространённые слова и названия брендов уже заняты. Рекомендуется объединить префикс компании, среду (prod/dev) и назначение (store/media), а при необходимости добавить случайный суффикс: например, contosoprodmedia7x2.

Каждая учётная запись хранения имеет два 512-битных ключа доступа, предоставляющих полный административный доступ ко всему содержимому учётной записи. С этими ключами следует обращаться как с паролями — хранить их в Azure Key Vault, а не в коде или файлах конфигурации. Azure создаёт два ключа, чтобы Вы могли выполнять ротацию ключей без простоя: обновите приложения, чтобы они использовали Key 2, затем создайте заново Key 1, переключите приложения на Key 1 и после этого создайте заново Key 2. Для более детального управления доступом используйте Shared Access Signatures (SAS) или Azure RBAC, а не передавайте главные ключи.

Azure RBAC (Role-Based Access Control) — рекомендуемый способ авторизации доступа к данным хранилища без передачи ключей. Назначьте роль Storage Blob Data Reader, чтобы разрешить доступ только для чтения к Blob Storage, или роль Storage Blob Data Contributor для чтения и записи. Эти роли назначаются пользователям, группам или управляемым удостоверениям Entra ID, поэтому доступ связан с аутентифицированным удостоверением, а не с общим секретом. Авторизация RBAC для хранилища доступна для служб Blob, Queue и Table (но не File — эта служба использует протоколы SMB/NFS со своими средствами управления доступом).

По умолчанию учётные записи хранения принимают подключения из любой сети. Для защиты рабочей среды ограничьте доступ с помощью брандмауэра Storage Account: разрешите только определённые диапазоны общедоступных IP-адресов или подсети виртуальной сети. Для максимальной безопасности полностью отключите доступ из общедоступного интернета и используйте Private Endpoint — частный IP-адрес внутри Вашей виртуальной сети, который направляет трафик к учётной записи хранения через частную магистраль Azure, не выставляя её в общедоступный интернет. Private Endpoints рекомендуется использовать для учётных записей хранения, содержащих конфиденциальные данные или данные, подпадающие под нормативные требования.

Azure Storage предоставляет встроенные функции защиты данных от случайного удаления: мягкое удаление Blob — удалённые объекты Blob и их версии хранятся в течение настраиваемого периода (от 1 до 365 дней) и могут быть восстановлены без восстановления из резервной копии. Управление версиями Blob — каждая перезапись создаёт новую версию, поэтому Вы можете восстановить любую предыдущую версию объекта Blob. Мягкое удаление контейнеров — случайно удалённые контейнеры можно восстановить. По умолчанию эти функции отключены; их следует включить для рабочих учётных записей хранения с важными данными, которые не резервируются в другом месте.

Azure Monitor автоматически собирает метрики для каждой учётной записи хранения: общий использованный объём, количество транзакций, число байтов входящего и исходящего трафика, а также сквозную задержку. Просматривать их можно на вкладке Insights портала Azure для Вашей учётной записи хранения; там доступны готовые диаграммы ёмкости, доступности и производительности. Для подробного аудита доступа включите журналы диагностики Storage, чтобы записывать каждую операцию чтения, записи и удаления в место назначения журналов — это полезно для расследований инцидентов безопасности и подготовки отчётов о соответствии требованиям.

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900), рассмотренных в этом уроке.

В этом уроке Вы узнали, что учётная запись хранения — это корневой ресурс для всех служб хранения Azure, который определяется глобально уникальным именем, варианты избыточности — LRS, ZRS, GRS и GZRS — обеспечивают всё более высокий уровень долговечности при увеличении стоимости, а доступ следует контролировать с помощью RBAC и частных конечных точек, а не передавать главные ключи доступа. Далее мы подробно рассмотрим Blob Storage — объектное хранилище Azure для неструктурированных данных.