Azure Storage Accounts — це фундаментальні сервіси в Microsoft Azure, які забезпечують масштабоване, захищене та високо доступне хмарне зберігання для різних типів даних, включаючи blobs (binary large objects), files, queues та tables. Вони слугують контейнерами, що групують ці різні сервіси зберігання під одним простором імен для зручного керування.
Основні параметри конфігурації:
Кожен обліковий запис сховища повинен мати унікальне ім’я в межах усього Azure.
Кожен обліковий запис розгортається в регіоні або в розширеній зоні Azure
Можна обрати premium версію облікового запису сховища для покращеної продуктивності
Можна вибрати серед 4 типів надмірності для захисту від відмов стійки, диска та дата-центру.
Параметри конфігурації безпеки:
Require secure transfer for REST API operations: Вимагати TLS у будь-якій комунікації зі сховищем
Allows enabling anonymous access on individual containers: Якщо ні — у майбутньому неможливо буде ввімкнути анонімний доступ
Enable storage account key access: Якщо ні — доступ за допомогою Shared Keys буде заборонено
Minimum TLS version
Permitted scope for copy operations: Дозволяти з будь-якого storage account, з будь-якого storage account того самого Entra tenant або з облікового запису зі private endpoints в тій же virtual network.
Blob Storage options:
Allow cross-tenant replication
Access tier: Hot (часто доступні дані), Cool та Cold (рідко доступні дані)
Параметри мережі:
Network access:
Дозволити з усіх мереж
Дозволити з вибраних virtual networks та IP-адрес
Вимкнути публічний доступ і використовувати приватний доступ
Private endpoints: Дозволяє приватне з’єднання до облікового запису сховища з virtual network
Параметри захисту даних:
Point-in-time restore for containers: Дозволяє відновити контейнери до попереднього стану
Потребує ввімкнених versioning, change feed та blob soft delete.
Enable soft delete for blobs: Вмикає період збереження в днях для видалених blobs (навіть перезаписаних)
Enable soft delete for containers: Вмикає період збереження в днях для видалених контейнерів
Enable soft delete for file shares: Вмикає період збереження в днях для видалених file shares
Enable versioning for blobs: Зберігати попередні версії ваших blobs
Enable blob change feed: Зберігати журнали створення, зміни та видалення blobs
Enable version-level immutability support: Дозволяє встановити політику зберігання на основі часу на рівні облікового запису, яка застосовуватиметься до всіх версій blob.
Version-level immutability support і point-in-time restore for containers не можна ввімкнути одночасно.
Параметри конфігурації шифрування:
Encryption type: Можна використовувати Microsoft-managed keys (MMK) або Customer-managed keys (CMK)
Enable infrastructure encryption: Дозволяє подвійне шифрування даних для підвищення безпеки
Static websites подаються з спеціального контейнера $web через регіонально-залежну кінцеву точку, наприклад https://<account>.z13.web.core.windows.net/.
Контейнер $web може повідомляти publicAccess: null через blob API, але файли все ще доступні через endpoint статичного сайту, тому розміщення конфігураційних/IaC артефактів там може leak secrets.
Швидкий робочий процес аудиту:
# Identify storage accounts with static website hosting enabled
az storage blob service-properties show --account-name <acc-name> --auth-mode login
# Enumerate containers (including $web) and their public flags
az storage container list --account-name <acc-name> --auth-mode login
# List files served by the static site even when publicAccess is null
az storage blob list --container-name '$web' --account-name <acc-name> --auth-mode login
# Pull suspicious files directly (e.g., IaC tfvars containing secrets/SAS)
az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdout --account-name <acc-name> --auth-mode login
Знайти storage accounts які можуть розкрити дані: az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'. Якщо allowBlobPublicAccess має значення false, ви не зможете зробити containers публічними.
Перевірити ризикові облікові записи щоб підтвердити прапорець та інші слабкі налаштування: az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'.
Перелічити експозицію на рівні контейнерів там, де прапорець увімкнено:
az storage container list --account-name <acc> \
--query '[].{name:name, access:properties.publicAccess}'
"Blob": анонімне читання дозволено лише коли відоме ім’я blob (без переліку).
"Container": анонімний перелік + читання кожного blob.
null: приватний; потрібна автентифікація.
Підтвердіть доступ без облікових даних:
Якщо publicAccess є Container, анонімний перелік працює: curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list".
Для обох Blob та Container, анонімне завантаження blob працює, якщо відоме ім’я:
az storage blob download -c <container> -n <blob> --account-name <acc> --file /dev/stdout
# or via raw HTTP
curl "https://<acc>.blob.core.windows.net/<container>/<blob>"
Можна generate Shared Keys, підписані ключами доступу, щоб авторизувати доступ до певних ресурсів через підписаний URL.
Note
Зверніть увагу, що частина CanonicalizedResource представляє ресурс сервісу сховища (URI). І якщо якась частина в URL закодована, вона також повинна бути закодована всередині CanonicalizedResource.
Note
Це за замовчуванням використовується az cli для автентифікації запитів. Щоб змусити його використовувати облікові дані принципала Entra ID, вкажіть параметр --auth-mode login.
Можна згенерувати shared key for blob, queue and file services підписавши наступну інформацію:
Shared Access Signatures (SAS) — це безпечні, обмежені в часі URL, які надають конкретні дозволи для доступу до ресурсів у обліковому записі Azure Storage без розкриття ключів доступу облікового запису. У той час як ключі доступу забезпечують повний адміністративний доступ до всіх ресурсів, SAS дозволяє здійснювати дрібнозерняний контроль, вказуючи дозволи (наприклад, read або write) та визначаючи час закінчення дії.
User delegation SAS: Створюється від імені Entra ID principal, який підписує SAS і делегує дозволи від користувача до SAS. Може використовуватися лише з blob and data lake storage (docs). Можна відкликати усі згенеровані user delegated SAS.
Навіть якщо можливо згенерувати delegation SAS з “більшими” дозволами, ніж має користувач, якщо principal не має цих дозволів, це не спрацює (немає privesc).
Service SAS: Підписується за допомогою одного з access keys облікового запису. Може використовуватися для надання доступу до конкретних ресурсів у межах однієї storage service. Якщо ключ оновлено, SAS перестане працювати.
Account SAS: Також підписується одним із access keys облікового запису. Надає доступ до ресурсів у різних службах облікового запису (Blob, Queue, Table, File) і може включати операції на рівні служби.
При генерації SAS потрібно вказати дозволи, які він має надавати. Залежно від об’єкта, для якого створюється SAS, можуть бути включені різні дозволи. Наприклад:
Azure Blob Storage тепер підтримує SSH File Transfer Protocol (SFTP), що дозволяє безпечну передачу файлів і керування безпосередньо в Blob Storage без потреби у власних рішеннях або сторонніх продуктах.
Protocol Support: SFTP працює з Blob Storage accounts, сконфігурованими з hierarchical namespace (HNS). Це організовує blobs у директорії та піддиректорії для простішої навігації.
Security: SFTP використовує локальні ідентичності користувачів для автентифікації і не інтегрується з RBAC або ABAC. Кожен локальний користувач може автентифікуватися через:
Azure-generated passwords
Public-private SSH key pairs
Granular Permissions: Permissions such as Read, Write, Delete, and List can be assigned to local users for up to 100 containers.
Networking Considerations: SFTP connections are made through port 22. Azure supports network configurations like firewalls, private endpoints, or virtual networks to secure SFTP traffic.
az storage blob show –account-name –container-name –sas-token ‘se=2024-12-31T23%3A59%3A00Z&sp=racwdxyltfmei&sv=2022-11-02&sr=c&sig=ym%2Bu%2BQp5qqrPotIK5/rrm7EMMxZRwF/hMWLfK1VWy6E%3D’ –name ‘asd.txt’