Model kontrol akses di Azure Data Lake Storage Gen2
Data Lake Storage Gen2 mendukung mekanisme otorisasi berikut:
- Otorisasi Kunci Bersama
- Otorisasi tanda tangan akses bersama (SAS)
- Kontrol akses berbasis peran (Azure RBAC)
- Kontrol akses berbasis atribut (Azure ABAC)
- Daftar kontrol akses (ACL)
Otorisasi Kunci Bersama dan SAS memberikan akses ke pengguna (atau aplikasi) tanpa mengharuskan mereka memiliki identitas di ID Microsoft Entra. Dengan dua bentuk autentikasi ini, Azure RBAC, Azure ABAC, dan ACL tidak berpengaruh.
Azure RBAC dan ACL mengharuskan pengguna (atau aplikasi) untuk memiliki identitas di ID Microsoft Entra. Azure RBAC memungkinkan Anda memberikan akses "kasar" ke data akun penyimpanan, seperti akses baca atau tulis ke semua data di akun penyimpanan. Azure ABAC memungkinkan Anda menyempurnakan penetapan peran RBAC dengan menambahkan kondisi. Misalnya, Anda dapat memberikan akses baca atau tulis ke semua objek data di akun penyimpanan yang memiliki tag tertentu. ACL memungkinkan Anda memberikan akses "halus", seperti akses tulis ke direktori atau file tertentu.
Artikel ini berfokus pada Azure RBAC, ABAC, dan ACL, dan bagaimana sistem mengevaluasinya bersama-sama untuk membuat keputusan otorisasi untuk sumber daya akun penyimpanan.
Kontrol akses berbasis peran (Azure RBAC)
Azure RBAC menggunakan penetapan peran untuk menerapkan sekumpulan izin ke prinsip keamanan. Prinsip keamanan adalah objek yang mewakili pengguna, grup, perwakilan layanan, atau identitas terkelola yang ditentukan dalam ID Microsoft Entra. Set izin dapat memberi prinsip keamanan tingkat akses "kasar" seperti akses baca atau tulis ke semua data dalam akun penyimpanan atau semua data dalam wadah.
Peran berikut mengizinkan prinsip keamanan untuk mengakses data di akun penyimpanan.
| Peran | Deskripsi |
|---|---|
| Pemilik Data Blob Penyimpanan | Akses penuh ke kontainer dan data penyimpanan Blob. Akses ini memungkinkan prinsip keamanan untuk mengatur pemilik item, dan untuk memodifikasi ACL dari semua item. |
| Data blob penyimpanan kontributor | Baca, tulis, dan hapus akses ke kontainer penyimpanan Blob dan blob. Akses ini tidak mengizinkan prinsip keamanan untuk mengatur kepemilikan item, tetapi dapat memodifikasi ACL dari item yang dimiliki oleh prinsip keamanan. |
| Pembaca Data Blob Penyimpanan. | Baca dan daftar kontainer penyimpanan Blob dan blob. |
Peran seperti Pemilik, Kontributor, Pembaca, dan Kontributor Akun Penyimpanan mengizinkan prinsip keamanan untuk mengelola akun penyimpanan, tetapi tidak memberikan akses ke data di dalam akun tersebut. Namun, peran ini (tidak termasuk Pembaca) dapat memperoleh akses ke kunci penyimpanan, yang dapat digunakan di berbagai alat klien untuk mengakses data.
Kontrol akses berbasis atribut (Azure ABAC)
Azure ABAC dibangun pada Azure RBAC dengan menambahkan kondisi penetapan peran berdasarkan atribut dalam konteks tindakan tertentu. Kondisi penetapan peran adalah pemeriksaan tambahan yang dapat Anda tambahkan secara opsional ke penetapan peran Anda untuk memberikan kontrol akses yang lebih halus. Anda tidak dapat secara eksplisit menolak akses ke sumber daya tertentu menggunakan kondisi.
Untuk informasi selengkapnya tentang menggunakan Azure ABAC untuk mengontrol akses ke Azure Storage, lihat Mengotorisasi akses ke Azure Blob Storage menggunakan kondisi penetapan peran Azure.
Daftar kontrol akses (ACL)
ACL memberi Anda kemampuan untuk menerapkan tingkat akses "yang lebih halus" ke direktori dan file. ACL adalah konstruksi izin yang berisi serangkaian entri ACL. Setiap entri ACL mengaitkan prinsip keamanan dengan tingkat akses. Untuk mempelajari ACL lebih lanjut, lihat Mengelola Daftar kontrol akses (ACL) di Azure Data Lake Storage Gen2.
Cara izin dievaluasi
Selama otorisasi berbasis perwakilan keamanan, izin dievaluasi seperti yang ditunjukkan dalam diagram berikut.
- Azure menentukan apakah penetapan peran ada untuk prinsipal.
- Jika penetapan peran ada, kondisi penetapan peran (2) dievaluasi berikutnya.
- Jika tidak, ACL (4) dievaluasi berikutnya.
- Azure menentukan apakah ada kondisi penetapan peran ABAC.
- Jika tidak ada kondisi, akses diberikan.
- Jika kondisi ada, mereka dievaluasi untuk melihat apakah mereka cocok dengan permintaan (3).
- Azure menentukan apakah semua kondisi penetapan peran ABAC cocok dengan atribut permintaan.
- Jika semuanya cocok, akses diberikan.
- Jika setidaknya salah satunya tidak cocok, ACL (4) akan dievaluasi berikutnya.
- Jika akses belum diberikan secara eksplisit setelah mengevaluasi penetapan dan kondisi peran, ACL dievaluasi.
- Jika ACL mengizinkan tingkat akses yang diminta, akses diberikan.
- Jika tidak, akses ditolak.
Penting
Karena cara izin akses dievaluasi oleh sistem, Anda tidak dapat menggunakan ACL untuk membatasi akses yang telah diberikan oleh penetapan peran dan kondisinya. Itu karena sistem mengevaluasi penetapan dan kondisi peran Azure terlebih dahulu, dan jika penugasan memberikan izin akses yang memadai, ACL diabaikan.
Diagram berikut menunjukkan alur izin untuk tiga operasi umum: mencantumkan konten direktori, membaca file, dan menulis file.
Tabel izin: Menggabungkan Azure RBAC, ABAC, dan ACL
Tabel berikut ini memperlihatkan kepada Anda cara menggabungkan peran, kondisi, dan entri ACL Azure sehingga prinsip keamanan dapat melakukan operasi yang tercantum di kolom Operasi . Tabel ini memperlihatkan kolom yang mewakili setiap tingkat hierarki direktori fiktif. Terdapat kolom untuk direktori akar kontainer (/), subdirektori bernama Oregon, subdirektori dari direktori Oregon bernama Portland, dan file teks di direktori Portland bernama Data.txt. Yang muncul di kolom tersebut adalah representasi bentuk pendek dari entri ACL yang diperlukan untuk memberikan izin. N/A (Tidak berlaku) muncul di kolom jika entri ACL tidak diperlukan untuk melakukan operasi.
| Operasi | Peran Azure yang ditetapkan (dengan atau tanpa kondisi) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Read Data.txt | pemilik Data Blob Penyimpanan | T/A | T/A | T/A | T/A |
| Data blob penyimpanan kontributor | T/A | T/A | T/A | T/A | |
| Pembaca Data Blob Penyimpanan | T/A | T/A | T/A | T/A | |
| Tidak ada | --X |
--X |
--X |
R-- |
|
| Tambahkan ke Data.txt | pemilik Data Blob Penyimpanan | T/A | T/A | T/A | T/A |
| Data blob penyimpanan kontributor | T/A | T/A | T/A | T/A | |
| Pembaca Data Blob Penyimpanan | --X |
--X |
--X |
-W- |
|
| Tidak ada | --X |
--X |
--X |
RW- |
|
| Hapus Data.txt | pemilik Data Blob Penyimpanan | T/A | T/A | T/A | T/A |
| Data blob penyimpanan kontributor | T/A | T/A | T/A | T/A | |
| Pembaca Data Blob Penyimpanan | --X |
--X |
-WX |
T/A | |
| Tidak ada | --X |
--X |
-WX |
T/A | |
| Buat Data.txt | pemilik Data Blob Penyimpanan | T/A | T/A | T/A | T/A |
| Data blob penyimpanan kontributor | T/A | T/A | T/A | T/A | |
| Pembaca Data Blob Penyimpanan | --X |
--X |
-WX |
T/A | |
| Tidak ada | --X |
--X |
-WX |
T/A | |
| Daftar / | pemilik Data Blob Penyimpanan | T/A | T/A | T/A | T/A |
| Data blob penyimpanan kontributor | T/A | T/A | T/A | T/A | |
| Pembaca Data Blob Penyimpanan | T/A | T/A | T/A | T/A | |
| Tidak ada | R-X |
T/A | T/A | T/A | |
| Daftar /Oregon/ | pemilik Data Blob Penyimpanan | T/A | T/A | T/A | T/A |
| Data blob penyimpanan kontributor | T/A | T/A | T/A | T/A | |
| Pembaca Data Blob Penyimpanan | T/A | T/A | T/A | T/A | |
| Tidak ada | --X |
R-X |
T/A | T/A | |
| Daftar /Oregon/Portland/ | pemilik Data Blob Penyimpanan | T/A | T/A | T/A | T/A |
| Data blob penyimpanan kontributor | T/A | T/A | T/A | T/A | |
| Pembaca Data Blob Penyimpanan | T/A | T/A | T/A | T/A | |
| Tidak ada | --X |
--X |
R-X |
T/A |
Catatan
Untuk melihat konten kontainer di Azure Storage Explorer, prinsip keamanan harus masuk ke Storage Explorer dengan menggunakan ID Microsoft Entra, dan (minimal) memiliki akses baca (R--) ke folder akar (\) kontainer. Tingkat izin ini memang memberikan kemampuan untuk mencantumkan isi folder akar. Jika Anda tidak ingin konten folder akar terlihat, Anda dapat menetapkan peran Pembaca. Dengan peran itu, izin ini akan dapat mencantumkan kontainer di akun, tetapi bukan konten kontainer. Anda kemudian dapat memberikan akses ke direktori dan file tertentu dengan menggunakan ACL.
Kelompok keamanan
Selalu gunakan grup keamanan Microsoft Entra sebagai prinsipal yang ditetapkan dalam entri ACL. Tolak kesempatan untuk secara langsung menugaskan pengguna individu atau perwakilan layanan. Menggunakan struktur ini akan memungkinkan Anda untuk menambahkan dan menghapus pengguna atau perwakilan layanan tanpa menerapkan kembali ACL ke seluruh struktur direktori. Sebagai gantinya, Anda dapat menambahkan atau menghapus pengguna dan perwakilan layanan dari grup keamanan Microsoft Entra yang sesuai.
Ada banyak cara berbeda untuk mengatur grup. Misalnya, bayangkan bahwa Anda memiliki direktori bernama /LogData yang menyimpan data log yang dihasilkan oleh server Anda. Azure Data Factory (ADF) menyerap data ke dalam folder tersebut. Pengguna tertentu dari tim teknik layanan akan mengunggah log dan mengelola pengguna lain dari folder ini, serta berbagai kluster Databricks akan menganalisis log dari folder tersebut.
Untuk mengaktifkan aktivitas ini, Anda bisa membuat grup LogsWriter dan grup LogsReader. Kemudian, Anda dapat menetapkan izin sebagai berikut:
- Tambahkan grup
LogsWriterke ACL direktori /LogData dengan izinrwx. - Tambahkan grup
LogsReaderke ACL direktori /LogData dengan izinr-x. - Tambahkan objek perwakilan layanan atau Identitas Layanan Terkelola (MSI) untuk ADF ke grup
LogsWriters. - Tambahkan pengguna di tim teknik layanan ke grup
LogsWriter. - Tambahkan objek perwakilan layanan atau MSI untuk Databricks ke grup
LogsReader.
Jika pengguna di tim teknik layanan meninggalkan perusahaan, Anda bisa menghapusnya dari grup LogsWriter. Jika Anda tidak menambahkan pengguna tersebut ke grup, tetapi sebaliknya, Anda menambahkan entri ACL khusus untuk pengguna tersebut, Anda harus menghapus entri ACL tersebut dari direktori /LogData. Anda juga harus menghapus entri dari semua subdirektori dan file di seluruh hierarki direktori dari direktori /LogData.
Untuk membuat grup dan menambahkan anggota, lihat Membuat grup dasar dan menambahkan anggota menggunakan ID Microsoft Entra.
Penting
Azure Data Lake Storage Gen2 bergantung pada ID Microsoft Entra untuk mengelola grup keamanan. ID Microsoft Entra merekomendasikan agar Anda membatasi keanggotaan grup untuk prinsip keamanan tertentu hingga kurang dari 200. Rekomendasi ini disebabkan oleh keterbatasan JSON Web Tokens (JWT) yang menyediakan informasi keanggotaan grup perwakilan keamanan dalam aplikasi Microsoft Entra. Melebihi batas ini dapat menyebabkan masalah performa yang tidak terduga dengan Data Lake Storage Gen2. Untuk mempelajari selengkapnya, lihat Mengonfigurasi klaim grup untuk aplikasi dengan menggunakan ID Microsoft Entra.
Batasan tugas peran Azure dan entri ACL
Dengan menggunakan grup, kemungkinan Anda akan melebihi jumlah maksimum penetapan peran per langganan dan jumlah maksimum entri ACL per file atau direktori. Tabel berikut ini menjelaskan batasan ini.
| Mekanisme | Scope | Batas | Tingkat izin yang didukung |
|---|---|---|---|
| Azure RBAC | Akun penyimpanan, kontainer. Penetapan peran Azure lintas sumber daya di tingkat langganan atau grup sumber daya. |
4000 penetapan peran Azure dalam langganan | Peran Azure (bawaan atau kustom) |
| ACL | Direktori, file | 32 entri ACL (efektif 28 entri ACL) per file dan per direktori. Akses dan ACL default masing-masing memiliki batas entri 32 ACL sendiri. | izin ACL |
Otorisasi Tanda Tangan Kunci Bersama dan Tanda Tangan Akses Bersama (SAS)
Azure Data Lake Storage Gen2 juga mendukung metode Kunci Bersama dan SAS untuk autentikasi. Karakteristik metode autentikasi ini adalah bahwa tidak ada identitas yang terkait dengan pemanggil dan oleh karena itu otorisasi berbasis izin utama keamanan tidak dapat dilakukan.
Dalam kasus Kunci Bersama, pemanggil secara efektif mendapatkan akses 'pengguna super', yang berarti akses penuh ke semua operasi pada semua sumber daya termasuk data, pemilik pengaturan, dan perubahan ACL.
Token SAS mencakup izin yang diizinkan sebagai bagian dari token. Izin yang termasuk dalam token SAS secara efektif diterapkan untuk semua keputusan otorisasi, tetapi tidak ada pemeriksaan ACL tambahan yang dilakukan.
Langkah berikutnya
Untuk mempelajari ACL lebih lanjut, lihat Daftar kontrol akses (ACL) di Azure Data Lake Storage Gen2.