Rangka kerja keselamatan Microsoft Azure menghadapi penelitian yang mendalam selepas penyelidik menemui kelemahan kritikal yang membolehkan penyerang menjejaskan kunci VPN dan menyusup masuk ke dalam rangkaian perusahaan. Penemuan ini, yang diterbitkan oleh Wiz Research Team , mendedahkan bagaimana peranan berlebihan dan kelemahan API mencipta pelbagai laluan serangan untuk pelaku berniat jahat.
Kelemahan ini berpusat di sekitar perkhidmatan REACT Azure , komponen dalaman Microsoft yang menguruskan tugasan peranan dan menukarkannya kepada definisi peranan. Walaupun direka bentuk untuk selamat dengan permukaan serangan yang kecil, penyelidik menemui cara untuk memanipulasi peranan ini dan memperoleh akses tanpa kebenaran kepada sumber kritikal.
Laluan Serangan VPN Azure:
- Penyerang memperoleh akses istimewa kepada Azure Connectors
- Menghitung semua gateway rangkaian maya (boleh dilakukan tanpa akses baca kepada langganan)
- Memanggil GET pada sumber sambungan gateway rangkaian maya
- Mendapatkan kunci berkongsi untuk akses VPN
- Memperoleh keupayaan penyusupan rangkaian
 |
|---|
| Meneroka Role Roulette Azure: Menganalisis bagaimana kelemahan mendedahkan rangkaian perusahaan |
Seni Bina Kompleks Mencipta Titik Buta Keselamatan
Pendekatan pembangunan teragih Azure telah mencipta labirin perkhidmatan yang saling berkaitan yang mana walaupun jurutera berpengalaman bergelut untuk menavigasinya. Dokumentasi platform ini terkenal berpecah-belah, dengan maklumat penting bertaburan merentasi pelbagai artikel. Kerumitan ini bukan sekadar isu kebolehgunaan - ia menjadi kebimbangan keselamatan yang serius.
Penyelidikan ini menyerlahkan bagaimana sistem kawalan akses berasaskan peranan Azure boleh dieksploitasi melalui kebenaran yang kelihatan tidak berbahaya. Penyerang dengan keistimewaan tinggi boleh menghitung get laluan rangkaian maya, mendapatkan semula kunci berkongsi, dan akhirnya memperoleh akses VPN kepada rangkaian perusahaan. Laluan serangan melibatkan panggilan permintaan GET pada sumber sambungan get laluan rangkaian maya, mendedahkan kunci berkongsi yang diperlukan untuk pengesahan VPN .
 |
|---|
| Memahami proses mendapatkan kunci berkongsi melalui operasi API Azure |
Pengalaman Pembangun Mencerminkan Masalah Yang Lebih Mendalam
Kekecewaan komuniti dengan Azure melangkaui isu keselamatan kepada pilihan reka bentuk asas. Ramai pembangun melaporkan bahawa Azure terasa seperti koleksi perkhidmatan yang dibina oleh pasukan berbeza dengan sedikit koordinasi, bukannya platform yang padu. Perpecahan ini muncul dalam segala-galanya daripada pertindihan perkhidmatan yang mengelirukan kepada proses penggunaan yang kompleks secara tidak perlu.
Agak jelas jika anda memeriksa github bahawa perkhidmatan dan dokumentasi Azure ditulis oleh pasukan teragih dengan sedikit koordinasi. Kami mempunyai pepatah dalaman bahawa maklumat semuanya ada dalam dokumen mereka, tetapi ayat dan perenggan untuk perkara remeh pun terpecah merentasi sepuluh atau lima belas artikel.
Pendekatan platform terhadap pengkomputeran tanpa pelayan amat mengecewakan pembangun. Tidak seperti AWS Lambda , yang membolehkan penggunaan fungsi secara langsung, Azure memerlukan pengguna untuk memperuntukkan pelan perkhidmatan, aplikasi fungsi, dan akaun storan walaupun untuk fungsi tanpa pelayan yang mudah. Kerumitan ini mencipta lebih banyak peluang untuk salah konfigurasi yang boleh membawa kepada kelemahan keselamatan.
Kerumitan Serverless Azure vs AWS:
- AWS Lambda: Pelaksanaan fungsi secara langsung
- Azure Functions: Memerlukan penyediaan pelan perkhidmatan + aplikasi fungsi + akaun storan + kumpulan sumber
- Azure menawarkan pelbagai jenis pelan (Consumption, Flex Consumption, App Service Plan)
- Kerumitan tambahan tanpa faedah yang jelas untuk kes penggunaan mudah
Penggunaan Perusahaan Walaupun Kekurangan Teknikal
Walaupun isu ini, Azure terus memperoleh pelanggan perusahaan, selalunya melalui hubungan perniagaan dan bukannya merit teknikal. Banyak organisasi memilih Azure kerana perkongsian Microsoft sedia ada, keperluan kediaman data, atau diskaun volum dan bukannya keutamaan kejuruteraan. Dinamik ini bermakna Microsoft menghadapi tekanan yang kurang untuk menangani kebimbangan kebolehgunaan dan keselamatan berbanding pesaing seperti AWS .
Penyelidikan ini mengesyorkan beberapa strategi mitigasi, termasuk mendesak untuk kemas kini kepada peranan bermasalah, melaksanakan prinsip keistimewaan paling sedikit, dan mengaudit peranan tersuai untuk kebenaran berlebihan. Walau bagaimanapun, isu asas kekal: seni bina kompleks Azure menyukarkan organisasi untuk mengamankan persekitaran awan mereka dengan betul.
Mitigasi Keselamatan yang Disyorkan:
- Audit dan gantikan peranan yang mempunyai keistimewaan berlebihan dengan alternatif keistimewaan minimum
- Laksanakan sekatan skop yang betul pada tugasan peranan
- Semakan berkala peranan tersuai untuk kebenaran yang berlebihan
- Desak untuk kemas kini kepada peranan Azure Connector yang bermasalah
- Pertimbangkan integrasi alternatif di mana boleh
 |
|---|
| Menguji API Azure: Kritikal untuk melaksanakan langkah-langkah keselamatan terhadap kelemahan |
Kesimpulan
Kelemahan ini menyerlahkan masalah yang lebih luas dengan postur keselamatan Azure dan kerumitan seni bina. Walaupun Microsoft mempunyai sumber untuk menangani isu ini, pendekatan pembangunan berpecah-belah platform terus mencipta permukaan serangan baharu. Organisasi yang menggunakan Azure harus mengaudit tugasan peranan mereka dengan teliti dan mempertimbangkan untuk melaksanakan langkah keselamatan tambahan untuk melindungi daripada vektor serangan yang baru ditemui ini.
Nota: REACT - perkhidmatan dalaman Microsoft untuk menguruskan tugasan peranan dan definisi dalam Azure Resource Manager
Rujukan: Azure's Role Renderers: How Over-Privileged Roles and API Vulnerabilities Expose Enterprise Networks