Saluran pembelian akaun awan Microsoft: Pengurusan hierarki penyimpanan Azure Blob dan konfigurasi keselamatan rantai anti-pencurian
Dalam era Internet mudah alih dan data besar, hampir setiap pasukan harus menghadapi masalah penyimpanan data tidak berstruktur secara besar-besaran. Sama ada avatar pengguna, audio dan video, atau PDF kontrak dalaman, log sistem, ia sering beratus-ratus TB atau bahkan PB.
Sekiranya semua fail ini dimasukkan ke dalam cakera keras pelayan tradisional, bukan sahaja pengembangannya memakan masa dan sukar, tetapi bil bulanan juga dapat membuat anda sakit. Pada masa ini,
Azure Blob Storage (Penyimpanan Objek Awan Microsoft)
Ia menjadi standard mutlak.
Tetapi apabila banyak pemula menggunakan Blob untuk menyimpan, mereka sering membuang semuanya dan sudah selesai. Ini membawa kepada dua akibat yang serius:
Pertama, sama ada avatar untuk lawatan frekuensi tinggi atau log yang tidak dibaca selama beberapa tahun, mereka semua ditagih dengan harga unit tinggi yang sama (pendarahan dompet); kedua, lalu lintas dicuri dengan jahat setelah pautan fail diumumkan, yang dihasilkan semalam Bil besar (lubang hitam keselamatan).
Tutorial hari ini tidak masuk akal, secara langsung akan membawa anda ke dua perkara utama penyimpanan Blob:
Pengurusan kitaran hidup hierarki (penjimatan wang) dan konfigurasi keselamatan rantai anti-kecurian SAS (tanpa bimbang).
1. Tahap pertama: selesaikan tiga tahap penyimpanan Blob (Access Tiers)
Azure Blob murah kerana membolehkan anda memilih kos penyimpanan yang berbeza berdasarkan "frekuensi akses" fail. Ia seperti penyimpanan pakaian, dibahagikan kepada tiga laci:
Lapisan penyimpanan haba (Hot): data yang sesuai untuk akses frekuensi tinggi. Contohnya, video yang disiarkan, avatar yang baru dimuat naik oleh pengguna. Ia mempunyai harga unit penyimpanan tertinggi, tetapi kos pengendalian untuk membaca fail hampir sifar.
Lapisan penyimpanan sejuk (Cool): Sesuai untuk akses frekuensi rendah (seperti tidak lebih dari sekali dalam 30 hari), tetapi memerlukan bacaan segera. Seperti bil bulan lalu, sandaran jangka pendek. Harga unit penyimpanan dikurangkan dengan ketara, tetapi sedikit "yuran keluar" akan dikenakan semasa membaca.
Arkib: Sesuai untuk data mati dengan sedikit akses (sebulan atau bahkan beberapa tahun) dan membolehkan beberapa jam kelewatan. Seperti log audit pematuhan, gambar perubatan sejarah. Harga penyimpanannya sangat murah sehingga dapat diabaikan, tetapi memerlukan beberapa jam untuk menunggu waktu pencairan untuk mengeluarkan fail (penghidratan/penghidratan).
2. Latihan pertempuran sebenar: gunakan "pengurusan kitaran hidup" untuk mewujudkan penjimatan wang automatik tanpa pengawasan
Sekiranya anda diminta untuk menukar tahap ribuan fail secara manual, anda mesti bekerja lebih masa hingga subuh. Azure menyediakan
"Pengurusan Kitaran Hidup"
Fungsi, anda hanya perlu menetapkan peraturan, dan selebihnya diserahkan kepada sistem untuk dilaksanakan secara automatik.
1. Konfigurasikan sasaran pemandangan
Kami mempunyai sekumpulan fail log sistem, yang perlu sering dilihat oleh pembangun dalam masa 7 hari yang baru dihasilkan. Pada dasarnya tidak ada yang menontonnya setelah 7 hari, tetapi ia perlu disimpan untuk rujukan. Setelah 180 hari, ia dikurangkan sepenuhnya menjadi data mati yang patuh dan mesti disimpan selama 7 tahun sebelum dapat dihapuskan.
2. Langkah-langkah Konfigurasi
Log masuk ke Azu
Re portal, masukkan akaun simpanan anda (Storage Account).
Cari dan klik "Pengurusan Kitaran Hidup"-> "Tambah Peraturan" di bar menu kiri.
Maklumat asas: Beri nama peraturan, seperti Log_Optimization_Rule. Skop peraturan memilih "Gunakan peraturan sekatan penapis" (ini hanya dapat berlaku untuk folder log tanpa merosakkan data lain secara tidak sengaja).
Konfigurasi set peraturan (logik IF/THEN): Langkah 1 (beralih ke penyimpanan sejuk): Jika fail pangkalan adalah masa pengubahsuaian terakhir melebihi (hari) -> masukkan 7. Kemudian lakukan operasi-> bergerak ke penyimpanan sejuk. Langkah 2 (Tukar ke Arkib): Klik Tambah Syarat. Jika pangkalan blog adalah pengubahsuaian terakhir lebih daripada (hari) -> masukkan 180. Kemudian lakukan operasi-> pindah ke penyimpanan arkib. Langkah 3 (Padam Secara Automatik): Jika Blob Base terakhir diubah suai lebih daripada (hari) -> masukkan 2555(7 tahun). Kemudian lakukan tindakan-> Padam blob.
Set penapis: Masukkan jalur folder log anda dalam padanan awalan, seperti logo/. Ini bermakna peraturan ini hanya berkuat kuasa untuk fail di bawah folder log.
Klik Simpan. Sekarang, akaun simpanan anda mempunyai "pengurus kewangan" terbina dalam, yang secara automatik akan memindahkan fail lama ke dalam laci murah setiap hari, secara automatik akan hancur apabila tamat tempoh, dan keluk bil akan lancar serta-merta.
3. Tahap kedua: menarik garis pertahanan keselamatan-mengapa "lawatan awam" tidak boleh digunakan?
Ramai pemula dapat menggunakan bahagian depan secara langsung
<Img src = "...">
Label memaparkan gambar, gambar menyelamatkan masalah dan secara langsung menetapkan tahap akses Container ke
"Awam"
。
Ini sama dengan membuka pintu gudang anda terus di Internet. Sesiapa yang mendapat URL ini boleh memanggilnya untuk memuat turun, atau menggunakan perayap multithreading untuk menanggalkan semua fail anda.
Anda bukan sahaja membocorkan privasi data, tetapi anda juga akan menerima peringatan tunggakan astronomi kerana lalu lintas menurun secara tiba-tiba (Egress).
Amalan terbaik dalam persekitaran pengeluaran: Kontena selalu "peribadi" dan hanya memberikan akses sementara dan terkawal melalui SAS (tandatangan akses bersama).
Keempat, perlindungan teras: konfigurasikan rantai anti-kecurian SAS (tandatangan akses bersama)
SAS(Shared Access Signature)
Prinsipnya adalah menambahkan rentetan token yang dienkripsi (Token) selepas URL fail peribadi yang asal. Token ini menetapkan
Siapa yang dapat mengakses fail ini dalam jangka waktu, izin apa, dan IP apa.
Pautan peribadi asal: htps:// m
Ystorage.blob.core.windows.net/media/cat.jpg (akses terus ke surat khabar 404/403)
▼ Selepas menambah token SAS
Pautan anti-kecurian: https://mystorage.blob.core.windows.net/media/cat.jpg? Sv = 2021-08-06 & ss = b & srt = o & sp = r & se = 2026-06-05T08:00:00Z & sip = 203.0.113.50 & sig = xxxx...
▲ ▲ ▲
(Masa tamat tempoh)
1. Pertempuran sebenar: menghasilkan token SAS dengan sekatan keselamatan
Sekiranya anda ingin menghasilkan pautan anti-pencurian ini secara dinamik dalam kod latar belakang, atau secara manual menghasilkannya sementara untuk pelanggan, anda boleh mengkonfigurasinya seperti ini di portal Azure:
Masukkan bekas Blob yang sesuai, periksa fail peribadi, dan klik tab "Buat SAS(Generate SAS)".
Akses (Permissions): Hanya tandakan "Baca". Jangan sekali-kali memberikan kebenaran menulis atau menghapus untuk mengelakkan fail tersebut dirusak secara jahat.
Tempoh sah (Expiry): Tetapkan masa tamat tempoh yang sangat singkat. Sekiranya laman web memaparkan gambar atau memuat turun lampiran, 15 minit hingga 1 jam sudah cukup. Setelah titik waktu ini terlampaui, pautan tersebut secara automatik tidak sah.
Alamat IP yang dibenarkan (alamat IP yang dibenarkan): * Senario keselamatan tinggi (anti-kecurian): isikan IP rangkaian awam pelayan depan anda atau IP eksport khusus pengguna. Dengan cara ini, walaupun orang lain menyalin pautan ini dengan SAS dan menghantarnya kepada orang lain dalam kumpulan WeChat, yang lain kerana
IP tidak sepadan dan tidak dapat dibuka sama sekali.
Protokol yang dibenarkan: Dikunci secara paksa "HTTPS sahaja".
Klik "Hasilkan token dan URL SAS" dan anda akan mendapat sambungan yang panjang. Sebarkan, selamat dan bebas dari kebimbangan.
2. Senibina lanjutan: proses SAS yang dihasilkan secara dinamik di bahagian belakang
Dalam sistem automatik sepenuhnya, logik pengguna front-end ketika mengunjungi laman web mestilah seperti ini:
Pengguna log masuk ke Aplikasi anda dan meminta untuk melihat invois peribadi.
Backend perniagaan anda (seperti perkhidmatan Java/Python/Node.js) menerima permintaan untuk mengesahkan bahawa pengguna mempunyai kebenaran untuk melihat.
Bahagian belakang memanggil Azure SDK untuk menghasilkan URL SAS secara dinamik dalam memori dengan tempoh sah hanya 5 minit dan hanya baca sahaja.
Bahagian belakang mengembalikan URL sementara ini ke bahagian depan, dan bahagian depan dimuat dengan selamat melalui penyemak imbas dalam masa 5 minit.
Lima minit kemudian, pautan itu menjadi kertas sampah di Internet, dan tidak berguna bagi penggodam untuk menggunakannya untuk penyebaran kedua.
5. Patch rantai anti-kecurian dan maju: digabungkan dengan Azure CDN
Walaupun SAS dapat menyelesaikan masalah pengesahan dan ketepatan masa dengan sempurna, jika fail anda adalah video awam untuk dimainkan oleh sebilangan besar pengguna di seluruh dunia (IP pengguna tidak dapat dibatasi), SAS sahaja mungkin masih tergila-gila dengan komplikasi yang tinggi.
Senibina utama pada masa ini adalah:
Tetapkan storan Blob secara peribadi, dan blok CDN Azure (rangkaian pengedaran kandungan) atau Pintu Depan Azure di bahagian depan.
Penyahmampatan cache CDN: Permintaan berulang pengguna secara langsung melanda simpul tepi CDN, lalu lintas tidak kembali ke Blob, dan kosnya merosot 90%.
Pautan anti-pencurian nama domain CDN (sekatan Referer): Buka "Pemeriksaan Tempoh Rujukan" di lapisan CDN, dan menetapkan bahawa hanya permintaan dari nama domain laman web anda sendiri (seperti https://www.mywebsite.com) yang dibenarkan untuk dilalui, dan secara langsung mencekik pencurian haram di garis paling luar Rujukan pautan luaran orang.
Ringkasan
Pengurusan fail besar-besaran tidak semudah "membuang".
Dengan menggunakan pengurusan kitaran hidup, anda membiarkan data belajar "metabolisme", meninggalkan penyimpanan panas yang mahal untuk perniagaan teras, membuang akaun lama ke dalam lapisan arkib beku, dan menjimatkan wang dengan postur yang paling elegan.
Dengan menggunakan bekas peribadi dan token SAS jangka pendek yang dinamik, anda melengkapkan setiap fail dengan kunci eksklusif dengan bom masa, mengucapkan selamat tinggal kepada mimpi buruk dicuri lalu lintas.
Menggabungkan kedua konfigurasi ini ke dalam reka bentuk sistem anda, seni bina penyimpanan awan anda benar-benar pintar dan hebat.
