Bagikan melalui


Praktik terbaik untuk memantau Azure Blob Storage

Artikel ini menampilkan kumpulan skenario pemantauan penyimpanan umum, serta memberi Anda panduan praktik terbaik untuk mencapainya.

Mengidentifikasi akun penyimpanan tanpa atau dengan penggunaan rendah

Wawasan Penyimpanan adalah dasbor di atas metrik dan log Azure Storage. Anda dapat menggunakan Wawasan Penyimpanan untuk memeriksa volume transaksi dan kapasitas yang digunakan dari semua akun Anda. Informasi itu dapat membantu Anda memutuskan akun mana yang mungkin ingin Anda nonaktifkan. Untuk mengonfigurasi Wawasan Penyimpanan, lihat Memantau layanan penyimpanan Anda dengan wawasan Penyimpanan Azure Monitor.

Menganalisis volume dari transaksi

Dari tampilan Wawasan Penyimpanan di monitor Azure, urutkan akun Anda dalam urutan menaik menggunakan kolom Transaksi. Gambar berikut menunjukkan akun dengan volume transaksi yang rendah selama periode yang ditentukan.

volume transaksi di Wawasan Penyimpanan

Klik tautan akun untuk mempelajari lebih lanjut tentang transaksi ini. Dalam contoh ini, sebagian besar permintaan akan dilakukan ke layanan Blob Storage.

transaksi menurut jenis layanan

Untuk menentukan jenis permintaan yang dibuat, lihat bagan Transaksi menurut nama API.

API transaksi penyimpanan

Dalam contoh ini, semua permintaan mencantumkan operasi ataupun permintaan informasi properti akun. Tidak terdapat transaksi baca dan tulis. Hal ini dapat menyebabkan Anda mengira bahwa akun tidak digunakan secara signifikan.

Menganalisis kapasitas digunakan

Dari tab Kapasitas pada tampilan Wawasan Penyimpanan di monitor Azure, urutkan akun Anda dalam urutan meningkatkan menggunakan kolom Kapasitas yang digunakan akun. Gambar berikut menunjukkan akun dengan volume kapasitas lebih rendah dibandingkan akun lainnya.

Kapasitas penyimpanan terpakai

Untuk memeriksa blob yang terkait dengan kapasitas yang digunakan, Anda dapat menggunakan Storage Explorer. Untuk blob dalam jumlah besar, pertimbangkan untuk membuat laporan dengan menggunakan kebijakan Inventaris Blob.

Memantau penggunaan dari kontainer

Jika Anda mempartisi data pelanggan Anda berdasarkan kontainer, maka dapat memantau jumlah kapasitas yang digunakan oleh setiap pelanggan. Anda dapat menggunakan persediaan blob Azure Storage untuk mengambil inventaris blob dengan informasi ukuran. Kemudian, Anda dapat mengumpulkan ukuran serta menghitung pada tingkat kontainer. Sebagai contoh, lihat Menghitung jumlah blob dan ukuran total per penampung menggunakan inventaris Azure Storage.

Anda juga dapat mengevaluasi lalu lintas pada tingkat kontainer dengan mengkueri log. Untuk mempelajari selengkapnya tentang menulis kueri Log Analytic, lihat Log Analytics. Untuk mempelajari selengkapnya tentang skema log penyimpanan, lihat Azure Blob Storage memantau referensi data.

Berikut adalah kueri untuk mendapatkan jumlah transaksi baca serta jumlah byte yang dibaca pada setiap kontainer.

StorageBlobLogs
| where OperationName  == "GetBlob"
| extend ContainerName = split(parse_url(Uri).Path, "/")[1]
| summarize ReadSize = sum(ResponseBodySize), ReadCount = count() by tostring(ContainerName)

Kueri berikut menggunakan kueri serupa dengan tujuan mendapatkan informasi tentang operasi penulisan.

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)

Kueri di atas merujuk nama beberapa operasi karena lebih dari satu jenis operasi yang dapat dihitung sebagai operasi penulisan. Untuk mempelajari lebih lanjut tentang operasi mana yang dianggap sebagai operasi baca dan tulis, lihat harga Azure Blob Storage atau harga Azure Data Lake Storage.

Mengaudit aktivitas akun

Dalam banyak kasus, Anda harus mengaudit aktivitas akun penyimpanan Anda untuk menjamin keamanan dan kepatuhan. Operasi pada akun penyimpanan terbagi dalam dua kategori: Control Plane dan Data Plane.

Operasi control plane adalah permintaan Azure Resource Manager untuk membuat akun penyimpanan atau untuk memperbarui properti dari akun penyimpanan yang ada. Untuk informasi selengkapnya, lihat Azure Resource Manager.

Operasi data plane adalah operasi pada data di akun penyimpanan yang dihasilkan dari permintaan ke titik akhir layanan penyimpanan. Misalnya, operasi data plane dijalankan saat Anda mengunggah blob ke akun penyimpanan atau mengunduh blob dari akun penyimpanan. Untuk informasi lebih lanjut, lihat Azure Storage API.

Bagian ini menunjukkan kepada Anda bagaimana mengidentifikasi "kapan", "siapa", "apa" dan "bagaimana" tentang informasi control plane dan data plane.

Menampilkan operasi control plane

Operasi Resource Manager direkam pada log aktivitas Azure. Untuk melihat log aktivitas, buka akun penyimpanan Anda di portal Microsoft Azure, lalu pilih Log Aktivitas.

Log Aktivitas

Buka entri log apa pun dengan tujuan melihat JSON yang menjelaskan aktivitas tersebut. JSON berikut menunjukkan informasi "kapan", "apa" dan "bagaimana" tentang operasi control plane:

JSON Log Aktivitas

Ketersediaan informasi "siapa" tergantung pada metode autentikasi yang digunakan untuk melakukan operasi bidang kontrol. Jika otorisasi dilakukan oleh perwakilan keamanan Microsoft Entra, pengidentifikasi objek dari prinsip keamanan tersebut juga akan muncul dalam output JSON ini (Misalnya: "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Karena Anda mungkin tidak selalu melihat informasi terkait identitas lainnya seperti alamat email atau nama, pengenal objek selalu merupakan cara terbaik untuk mengidentifikasi prinsipal keamanan secara unik.

Anda dapat menemukan nama yang mudah diingat dari prinsip keamanan tersebut dengan mengambil nilai pengidentifikasi objek, dan mencari prinsip keamanan di halaman ID Microsoft Entra dari portal Azure. Cuplikan layar berikut menunjukkan hasil pencarian di ID Microsoft Entra.

Cari ID Microsoft Entra

Mengaudit operasi data plane

Operasi data plane direkam pada log sumber daya Azure untuk Storage. Anda dapat mengonfigurasi setelan Diagnostik untuk mengekspor log ke ruang kerja Log Analytics untuk pengalaman kueri asli.

Berikut adalah kueri Log Analytics yang mengambil informasi "kapan", "siapa", "apa", dan "bagaimana" di dalam daftar entri log.

StorageBlobLogs
| where TimeGenerated > ago(3d)
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri

Untuk bagian "kapan" dari audit Anda, bidang TimeGenerated menunjukkan kapan entri log direkam.

Untuk bagian "apa" dari audit Anda, bidang Uri menunjukkan kapan entri log direkam.

Untuk bagian "bagaimana" dari audit Anda, bidang OperationName menunjukkan kapan entri log direkam.

Tip

Misalnya, jika Anda menduga bahwa blob atau kontainer telah dihapus secara tidak sengaja, maka tambahkan where klausa yang hanya mengembalikan entri log di mana OperationName diatur ke Hapus blob atau Hapus Kontainer. Untuk bagian "siapa" dari audit Anda, AuthenticationType menunjukkan jenis autentikasi mana yang digunakan untuk mengajukan permintaan. Bidang ini dapat menampilkan salah satu jenis autentikasi yang didukung Azure Storage termasuk penggunaan kunci akun, token SAS, atau autentikasi Microsoft Entra.

Jika permintaan diotorisasi dengan menggunakan ID Microsoft Entra, Anda dapat menggunakan RequestObjectId bidang untuk mengidentifikasi "siapa". Kunci Bersama dan autentikasi SAS tidak menyediakan sarana untuk mengaudit identitas individu. Dalam kasus tersebut callerIPAddress , bidang dan userAgentHeader mungkin membantu Anda mengidentifikasi sumber operasi. Jika token SAS digunakan untuk mengotorisasi operasi, Anda dapat mengidentifikasi token tersebut, dan jika Anda telah memetakan token ke penerima token di akhir Anda, Anda dapat mengidentifikasi pengguna, organisasi, atau aplikasi mana yang telah melakukan operasi. Lihat Mengidentifikasi token SAS yang digunakan untuk mengotorisasi permintaan.

Mengidentifikasi perwakilan keamanan yang digunakan untuk mengotorisasi permintaan

Jika permintaan diautentikasi dengan menggunakan ID Microsoft Entra, RequesterObjectId bidang menyediakan cara yang paling dapat diandalkan untuk mengidentifikasi prinsip keamanan. Anda dapat menemukan nama yang mudah diingat dari prinsip keamanan tersebut dengan mengambil nilai RequesterObjectId bidang , dan mencari prinsip keamanan di halaman ID Microsoft Entra dari portal Azure. Cuplikan layar berikut menunjukkan hasil pencarian di ID Microsoft Entra.

Cari ID Microsoft Entra

Dalam beberapa kasus, nama utama pengguna atau UPN mungkin muncul di log. Misalnya, jika prinsip keamanan adalah pengguna Microsoft Entra, UPN kemungkinan akan muncul. Untuk jenis prinsip keamanan lainnya seperti identitas terkelola yang ditetapkan pengguna, atau dalam skenario tertentu seperti autentikasi lintas penyewa Microsoft Entra, UPN tidak akan muncul di log.

Kueri ini menampilkan semua operasi baca yang dilakukan oleh prinsipal keamanan OAuth.

StorageBlobLogs
| where TimeGenerated > ago(3d)
  and OperationName == "GetBlob"
  and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri

Kunci Bersama dan autentikasi SAS tidak menyediakan sarana untuk mengaudit identitas individu. Oleh karena itu, jika Anda ingin meningkatkan kemampuan Anda untuk mengaudit berdasarkan identitas, kami sarankan Anda beralih ke ID Microsoft Entra, dan mencegah kunci bersama dan autentikasi SAS. Untuk mempelajari cara mencegah Kunci Bersama dan autentikasi SAS, lihat Mencegah otorisasi Kunci Bersama untuk akun Azure Storage. Untuk mulai menggunakan ID Microsoft Entra, lihat Mengotorisasi akses ke blob menggunakan ID Microsoft Entra.

Mengidentifikasi token SAS yang digunakan untuk mengotorisasi permintaan

Anda dapat mengkueri operasi yang diizinkan menggunakan token SAS. Misalnya, kueri ini mengembalikan semua operasi tulis yang diotorisasi menggunakan token SAS.

StorageBlobLogs
| where TimeGenerated > ago(3d)
  and OperationName == "PutBlob"
  and AuthenticationType == "SAS"
| project TimeGenerated, AuthenticationType, AuthenticationHash, OperationName, Uri

Untuk alasan keamanan, token SAS tidak muncul di log. Namun, hash SHA-256 dari tanda tangan token SAS akan muncul di AuthenticationHash bidang yang dikembalikan oleh kueri ini.

Jika Anda telah mendistribusikan beberapa token SAS, dan ingin mengetahui token SAS mana yang digunakan, Anda harus mengonversi bagian tanda tangan dari setiap token SAS Anda menjadi hash SHA-256, lalu membandingkan hash tersebut dengan nilai hash yang muncul di log.

Pertama, dekode setiap string token SAS. Contoh berikut mendekode bagian tanda tangan dari string token SAS dengan menggunakan PowerShell.

[uri]::UnescapeDataString("<SAS signature here>")

Anda dapat menggunakan alat atau SDK apa pun untuk mengonversi tanda tangan yang didekodekan ke SHA-256 yang memiliki tanda tangan tersebut. Misalnya, pada sistem Linux, Anda dapat menggunakan perintah berikut:

echo -n "<Decoded SAS signature>" | python3 -c "import sys; from urllib.parse import unquote; print(unquote(sys.stdin.read()), end='');"  | sha256sum

Cara lain untuk mengonversi tanda tangan yang didekodekan adalah dengan meneruskan string yang didekodekan ke fungsi hash_sha256() sebagai bagian dari kueri saat Anda menggunakan Azure Data Explorer.

Token SAS tidak berisi informasi identitas. Salah satu cara untuk melacak aktivitas pengguna atau organisasi adalah dengan menjaga pemetaan pengguna atau organisasi ke berbagai hash token SAS.

Mengoptimalkan biaya untuk kueri yang jarang terjadi

Anda dapat mengekspor log ke Log Analytics untuk kemampuan kueri asli yang kaya. Saat Anda memiliki transaksi dalam jumlah besar di akun penyimpanan Anda, biaya penggunaan log dengan Log Analytics mungkin tinggi. Untuk informasi selengkapnya, lihat Harga Analitik Log Azure. Jika Anda hanya berencana untuk mengkueri log sesekali (misalnya, log kueri untuk audit kepatuhan), Anda dapat mempertimbangkan untuk mengurangi total biaya dengan mengekspor log ke akun penyimpanan, lalu menggunakan solusi kueri tanpa server di atas data log, misalnya, Azure Synapse.

Dengan Azure Synapse, Anda dapat membuat kumpulan SQL tanpa server untuk meminta data log saat Anda membutuhkannya. Hal ini bisa menghemat biaya secara signifikan.

  1. Membuat rute log ke akun penyimpanan. Untuk informasi selengkapnya, lihat Membuat pengaturan diagnostik.

  2. Membuat dan mengonfigurasi ruang kerja Synapse. Untuk informasi selengkapnya, lihat Mulai Cepat: Buat ruang kerja Synapse.

  3. Log kueri. Untuk informasi selengkapnya, lihat Meminta file JSON menggunakan kumpulan SQL tanpa server di Azure Synapse Analytics.

    Berikut contohnya:

     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
    
    

Lihat juga