Bagikan melalui

Daftar kontrol akses (ACL) di Azure Data Lake Storage

  • Artikel

Azure Data Lake Storage menerapkan model kontrol akses yang mendukung kontrol akses berbasis peran Azure (Azure RBAC) dan daftar kontrol akses (ACL) seperti POSIX. Artikel ini menjelaskan daftar kontrol akses di Data Lake Storage. Untuk mempelajari tentang cara menggabungkan Azure RBAC bersama dengan ACL, dan bagaimana sistem mengevaluasinya untuk membuat keputusan otorisasi, lihat Model kontrol akses di Azure Data Lake Storage.

Tentang ACL

Anda dapat menghubungkan perwakilan keamanan dengan tingkat akses untuk file dan direktori. Setiap asosiasi ditangkap sebagai entri dalam daftar kontrol akses (ACL). Setiap file dan direktori di akun penyimpanan Anda memiliki daftar kontrol akses. Ketika perwakilan keamanan mencoba operasi pada file atau direktori, pemeriksaan ACL menentukan apakah prinsip keamanan (pengguna, grup, perwakilan layanan, atau identitas terkelola) memiliki tingkat izin yang benar untuk melakukan operasi.

Catatan

ACL hanya berlaku untuk prinsip keamanan di penyewa yang sama. ACL tidak berlaku untuk pengguna yang menggunakan otorisasi Kunci Bersama karena tidak ada identitas yang terkait dengan pemanggil dan oleh karena itu otorisasi berbasis izin utama keamanan tidak dapat dilakukan. Hal yang sama berlaku untuk token tanda tangan akses bersama (SAS) kecuali ketika token SAS yang didelegasikan pengguna digunakan. Dalam hal ini, Azure Storage melakukan pemeriksaan POSIX ACL terhadap ID objek sebelum mengotorisasi operasi selama suoid parameter opsional digunakan. Untuk mempelajari selengkapnya, lihat Membuat SAS delegasi pengguna.

Cara mengatur ACL

Untuk mengatur izin tingkat file dan direktori, lihat salah satu artikel berikut ini:

Lingkungan Artikel
Azure Storage Explorer Menggunakan Azure Storage Explorer untuk mengelola ACL di Azure Data Lake Storage
Portal Azure Menggunakan portal Azure untuk mengelola ACL di Azure Data Lake Storage
.NET Gunakan .NET untuk mengelola ACL di Azure Data Lake Storage
Java Menggunakan Java untuk mengelola ACL di Azure Data Lake Storage
Python Menggunakan Python untuk mengelola ACL di Azure Data Lake Storage
JavaScript (Node.js) Menggunakan JavaScript SDK di Node.js untuk mengelola ACL di Azure Data Lake Storage
PowerShell Menggunakan PowerShell untuk mengelola ACL di Azure Data Lake Storage
Azure CLI Menggunakan Azure CLI untuk mengelola ACL di Azure Data Lake Storage
REST API Jalur - Perbarui

Penting

Jika perwakilan keamanan adalah perwakilan layanan, penting untuk menggunakan ID objek dari perwakilan layanan dan bukan ID objek dari pendaftaran aplikasi terkait. Untuk mendapatkan ID objek dari perwakilan layanan, buka Azure CLI, lalu gunakan perintah ini: az ad sp show --id <Your App ID> --query objectId. Pastikan untuk mengganti <Your App ID> tempat penampung dengan ID Aplikasi pendaftaran aplikasi Anda. Perwakilan layanan diperlakukan sebagai pengguna bernama. Anda akan menambahkan ID ini ke ACL seperti yang Anda lakukan pada pengguna bernama apa pun. Pengguna bernama dijelaskan nanti di artikel ini.

Jenis ACL

Ada dua jenis daftar kontrol akses: mengakses ACL dan ACL default.

ACL akses mengontrol akses ke objek. File dan direktori keduanya memiliki ACL akses.

ACL default adalah templat ACL yang terkait dengan direktori yang menentukan ACL akses untuk setiap item anak yang dibuat di bawah direktori tersebut. File tidak memiliki ACL default.

Baik ACL akses dan ACL default memiliki struktur yang sama.

Catatan

Mengubah ACL default pada induk tidak memengaruhi ACL akses atau ACL default item anak yang sudah ada.

Tingkat izin

Izin pada direktori dan file dalam kontainer, adalah Baca, Tulis, dan Jalankan, dan dapat digunakan pada file dan direktori seperti yang diperlihatkan dalam tabel berikut:

File Direktori
Baca (R) Dapat membaca konten file Mengharuskan Baca dan Jalankan untuk mencantumkan konten direktori
Tulis (W) Dapat menulis atau menambahkan ke file Membutuhkan Tulis dan Jalankan untuk membuat item anak dalam direktori
Jalankan(X) Tidak berarti apa pun dalam konteks Data Lake Storage Diperlukan untuk melintasi item anak dari direktori

Catatan

Jika Anda memberikan izin dengan hanya menggunakan ACL (tidak ada Azure RBAC), maka untuk memberikan akses perwakilan keamanan membaca atau menulis ke file, Anda harus memberikan izin Jalankanpada perwakilan keamanan ke folder akar kontainer, dan untuk setiap folder dalam hierarki folder yang mengarah ke file tersebut.

Formulir singkat untuk izin

RWX digunakan untuk menunjukkan Baca + Tulis + Jalankan. Ada bentuk numerik yang lebih singkat di mana Baca=4, Tulis=2, dan Jalankan=1, yang jumlahnya mewakili semua izin tersebut. Berikut ini adalah beberapa contohnya.

Formulir numerik Formulir pendek Apa artinya
7 RWX Baca + Tulis + Jalankan
5 R-X Baca + Jalankan
4 R-- Read
0 --- Tidak ada izin

Pewarisan izin

Dalam model bergaya POSIX yang digunakan oleh Data Lake Storage, izin untuk item disimpan pada item itu sendiri. Dengan kata lain, izin untuk item tidak dapat diwariskan dari item induk jika izin diatur setelah item anak dibuat. Izin hanya diwariskan jika izin default telah disetel pada item induk sebelum item anak dibuat.

Tabel berikut ini memperlihatkan kepada Anda entri ACL yang diperlukan untuk mengaktifkan perwakilan keamanan untuk 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.

Penting

Tabel ini mengasumsikan bahwa Anda hanya menggunakan ACL tanpa penetapan peran Azure. Untuk melihat tabel serupa yang menggabungkan Azure RBAC bersama dengan ACL, lihat Tabel izin: Menggabungkan Azure RBAC, ABAC, dan ACL.

Operasi / Oregon/ Portland/ Data.txt
Read Data.txt --X --X --X R--
Tambahkan ke Data.txt --X --X --X RW-
Hapus Data.txt --X --X -WX ---
Hapus /Oregon/ -WX RWX RWX ---
Hapus /Oregon/Portland/ --X -WX RWX ---
Buat Data.txt --X --X -WX ---
Daftar / R-X --- --- ---
Daftar /Oregon/ --X R-X --- ---
Daftar /Oregon/Portland/ --X --X R-X ---

Menghapus file dan direktori

Seperti yang ditunjukkan pada tabel sebelumnya, izin tulis pada file tidak diperlukan untuk menghapusnya selama izin direktori diatur dengan benar. Namun, untuk menghapus direktori dan semua kontennya, direktori induk harus memiliki izin Tulis + Jalankan. Direktori yang akan dihapus, dan setiap direktori di dalamnya, memerlukan izin Baca + Tulis + Jalankan.

Catatan

Direktori akar "/" tidak pernah dapat dihapus.

Pengguna dan identitas

Setiap file dan direktori memiliki ijin yang berbeda untuk identitas ini:

  • Pengguna pemilik
  • Grup pemilik
  • Pengguna bernama
  • Grup bernama
  • Perwakilan Layanan bernama
  • identitas terkelola bernama
  • Semua pengguna lain

Identitas pengguna dan grup adalah identitas Microsoft Entra. Jadi kecuali dinyatakan lain, pengguna, dalam konteks Data Lake Storage, dapat merujuk ke pengguna Microsoft Entra, perwakilan layanan, identitas terkelola, atau grup keamanan.

Pengguna super

Pengguna super memiliki hak terbanyak dari semua pengguna. Pengguna super:

  • Memiliki Izin RWX untuk semua file dan folder.

  • Dapat mengubah izin pada file atau folder mana pun.

  • Dapat mengubah pengguna pemilik atau grup pemilik file atau folder apa pun.

Jika kontainer, file, atau direktori dibuat menggunakan Kunci Bersama, SAS Akun, atau SAS Layanan, maka pemilik dan grup pemilik diatur ke $superuser.

Pengguna pemilik

Pengguna yang membuat item secara otomatis adalah pengguna pemilik item. Pengguna pemilik dapat:

  • Mengubah izin file yang dimiliki.
  • Mengubah grup pemilik file yang dimiliki, selama pengguna pemilik juga merupakan anggota grup target.

Catatan

Pengguna pemilik tidak dapat mengubah pengguna pemilik file atau direktori. Hanya pengguna super yang dapat mengubah pengguna pemilik file atau direktori.

Grup pemilik

Dalam ACL POSIX, setiap pengguna terhubung dengan grup utama. Misalnya, pengguna "Alice" mungkin termasuk dalam grup "keuangan". Alice mungkin juga termasuk dalam beberapa grup, tetapi hanya satu grup yang ditetapkan sebagai grup utama mereka. Di POSIX, saat Alice membuat file, grup pemilik file tersebut diatur ke grup utamanya, yang dalam hal ini adalah "keuangan". Grup pemilik berperilaku serupa dengan izin yang ditetapkan untuk pengguna/grup lain.

Menetapkan grup pemilik untuk file atau direktori baru

  • Kasus 1: Direktori akar /. Direktori ini dibuat saat kontainer Data Lake Storage dibuat. Dalam hal ini, grup pemilik diatur ke pengguna yang membuat kontainer jika dilakukan menggunakan OAuth. Jika kontainer dibuat menggunakan Kunci Bersama, Akun SAS, atau Layanan SAS, maka pemilik dan grup pemilik diatur ke $superuser.
  • Kasus 2 (setiap kasus lain): Saat item baru dibuat, grup pemilik disalin dari direktori induk.

Mengubah grup pemilik

Grup pemilik dapat diubah oleh:

  • Semua pengguna super.
  • Pengguna pemilik, jika pengguna pemilik juga merupakan anggota grup target.

Catatan

Grup pemilik tidak dapat mengubah ACL file atau direktori. Meskipun grup pemilik diatur ke pengguna yang membuat akun dalam kasus direktori akar, Kasus 1 di atas, satu akun pengguna tidak valid untuk memberikan izin melalui grup pemilik. Anda bisa menetapkan izin ini ke grup pengguna yang berlaku jika ada.

Cara izin dievaluasi

Identitas dievaluasi dalam urutan berikut:

  1. sebagai superuser
  2. Pengguna pemilik
  3. Pengguna yang dinamai, perwakilan layanan, atau identitas terkelola
  4. Memiliki grup atau grup bernama
  5. Semua pengguna lain

Jika lebih dari satu identitas ini berlaku untuk kepala keamanan, maka tingkat izin yang terkait dengan identitas pertama diberikan. Misalnya, jika kepala keamanan adalah pengguna pemilik dan pengguna bernama, maka tingkat izin yang terkait dengan pengguna pemilik berlaku.

Grup bernama semuanya dipertimbangkan bersama. Jika prinsipal keamanan adalah anggota lebih dari satu grup bernama, maka sistem akan mengevaluasi setiap grup hingga izin yang diinginkan diberikan. Jika tidak ada grup bernama yang memberikan izin yang diinginkan, maka sistem akan melanjutkan untuk mengevaluasi permintaan terhadap izin yang terkait dengan semua pengguna lain.

Kode semu berikut ini menunjukkan algoritma pemeriksaan akses untuk akun penyimpanan. Algoritma ini menunjukkan urutan di mana identitas dievaluasi.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

Masker

Seperti yang diilustrasikan dalam Algoritma Pemeriksaan Akses, masker membatasi akses untuk pengguna bernama, grup pemilik, dan grup bernama.

Untuk kontainer Data Lake Storage baru, masker untuk akses ACL direktori akar ("/") default ke 750 untuk direktori dan 640 untuk file. Tabel berikut ini memperlihatkan notasi simbolis dari tingkat izin ini.

Entity Direktori File
Pengguna pemilik rwx rw-
Grup pemilik r-x r--
Lainnya --- ---

File tidak menerima X bit karena tidak relevan dengan file dalam sistem toko-saja.

Masker dapat ditentukan berdasarkan per panggilan. Ini memungkinkan sistem konsumsi yang berbeda, seperti kluster, untuk memiliki masker efektif yang berbeda untuk operasi file mereka. Jika masker ditentukan berdasarkan permintaan tertentu, masker akan sepenuhnya menggantikan masker default.

Bit lekat

Bit lekat adalah fitur yang lebih canggih dari kontainer POSIX. Dalam konteks Data Lake Storage, tidak mungkin bit lengket akan diperlukan. Ringkasnya, jika bit lekat dikatifkan pada direktori, anak item hanya dapat dihapus atau diganti nama oleh pengguna pemilik anak item, pemilik direktori, atau Superuser ($superuser).

Bit lekat tidak ditampilkan di portal Microsoft Azure. Untuk mempelajari selengkapnya tentang bit lengket dan cara mengaturnya, lihat Apa itu Data Lake Storage bit lengket?.

Izin default pada file dan direktori baru

Saat file atau direktori baru dibuat di bawah direktori yang sudah ada, ACL default pada direktori induk menentukan:

  • ACL default direktori anak dan mengakses ACL.
  • ACL akses file anak (file tidak memiliki ACL default).

umask

Saat membuat ACL default, umask diterapkan ke ACL akses untuk menentukan izin awal ACL default. Jika ACL default ditentukan di direktori induk, umask secara efektif diabaikan dan ACL default direktori induk digunakan untuk menentukan nilai awal ini sebagai gantinya.

umask adalah nilai 9-bit pada direktori induk yang berisi nilai RWX untuk pengguna pemilik, grup pemilik, dan lainnya.

Umask untuk Azure Data Lake Storage nilai konstanta yang diatur ke 007. Nilai ini diterjemahkan menjadi:

komponen umask Formulir numerik Formulir pendek Makna
umask.owning_user 0 --- Untuk pengguna pemilik, salin ACL akses induk ke ACL default turunan
umask.owning_group 0 --- Untuk grup pemilik, salin ACL akses induk ke ACL default turunan
umask.other 7 RWX Untuk yang lain, hapus semua izin pada ACL akses anak

FAQ

Apakah saya harus mengaktifkan dukungan untuk ACL?

Tidak. Kontrol akses melalui ACL diaktifkan untuk akun penyimpanan selama fitur Namespace Hierarki (HNS) diaktifkan.

Jika HNS dinonaktifkan, aturan otorisasi Azure RBAC masih berlaku.

Apa cara terbaik untuk menerapkan ACL?

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 LogsWriter ke ACL direktori /LogData dengan izin rwx.
  • Tambahkan grup LogsReader ke ACL direktori /LogData dengan izin r-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.

Bagaimana izin Azure RBAC dan ACL dievaluasi?

Untuk mempelajari bagaimana sistem mengevaluasi Azure RBAC dan ACL bersama-sama untuk membuat keputusan otorisasi untuk sumber daya akun penyimpanan, lihat Bagaimana izin dievaluasi.

Apa batasan untuk penetapan peran Azure dan entri ACL?

Tabel berikut ini menyediakan tampilan ringkasan batas yang perlu dipertimbangkan saat menggunakan Azure RBAC untuk mengelola izin "pokok" (izin yang berlaku untuk akun penyimpanan atau kontainer) dan menggunakan ACL untuk mengelola izin "detail" (izin yang berlaku untuk file dan direktori). Gunakan kelompok keamanan untuk tugas ACL. Dengan menggunakan grup, kemungkinan Anda akan melebihi jumlah maksimum penetapan peran per langganan dan jumlah maksimum entri ACL per file atau direktori.

Mekanisme Cakupan 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

Apakah Data Lake Storage mendukung pewarisan Azure RBAC?

Penetapan peran Azure diwariskan. Tugas alur dari langganan, grup sumber daya, dan sumber daya akun penyimpanan hingga ke sumber daya kontainer.

Apakah Data Lake Storage mendukung pewarisan ACL?

ACL default dapat digunakan untuk mengatur ACL untuk subdirectories dan file anak baru yang dibuat di bawah direktori induk. Untuk memperbarui ACL untuk item anak yang sudah ada, Anda harus menambahkan, memperbarui, atau menghapus ACL secara rekursif untuk hierarki direktori yang diinginkan. Untuk panduan, lihat bagian Cara mengatur ACL di artikel ini.

Izin mana yang diperlukan untuk menghapus direktori dan kontennya secara rekursif?

  • Pemanggil memiliki izin 'pengguna super',

Atau

  • Direktori induk harus memiliki izin Tulis + Jalankan.
  • Direktori yang akan dihapus, dan setiap direktori di dalamnya, memerlukan izin Baca + Tulis + Jalankan.

Catatan

Anda tidak memerlukan izin Tulis untuk menghapus file di dalam direktori. Juga, direktori akar "/" tidak pernah dapat dihapus.

Siapa pemilik file atau direktori?

Pembuat file atau direktori menjadi pemiliknya. Dalam kasus direktori akar, maka itu adala identitas pengguna yang membuat kontainer.

Grup mana yang ditetapkan sebagai grup pemilik file atau direktori saat dibuat?

Grup pemilik disalin dari grup pemilik direktori induk tempat file atau direktori baru dibuat.

Saya adalah pengguna pemilik file tetapi saya tidak memiliki izin RWX yang saya butuhkan. Apa yang harus saya lakukan?

Pengguna pemilik dapat mengubah izin file untuk memberi diri mereka sendiri izin RWX yang mereka butuhkan.

Mengapa saya kadang-kadang melihat GUID di ACL?

GUID ditampilkan jika entri mewakili pengguna dan pengguna tersebut tidak ada di Microsoft Entra lagi. Biasanya ini terjadi ketika pengguna telah meninggalkan perusahaan atau jika akun mereka telah dihapus di ID Microsoft Entra. Selain itu, perwakilan layanan dan kelompok keamanan tidak memiliki Nama Prinsipal Pengguna (UPN) untuk mengidentifikasi mereka dan sehingga mereka diwakili oleh atribut OID mereka (panduan). Untuk membersihkan ACL, hapus entri GUID ini secara manual.

Bagaimana cara mengatur ACL dengan benar untuk perwakilan layanan?

Saat Anda menentukan ACL untuk perwakilan layanan, penting untuk menggunakan Object ID (OID) dari perwakilan layanan untuk pendaftaran aplikasi yang Anda buat. Penting untuk dicatat bahwa aplikasi terdaftar memiliki perwakilan layanan terpisah di penyewa Microsoft Entra tertentu. Aplikasi terdaftar memiliki OID yang terlihat di portal Microsoft Azure, tetapi perwakilan layanan memiliki OID lain (berbeda). Artikel: Guna mendapatkan OID untuk perwakilan layanan yang sesuai dengan pendaftaran aplikasi, Anda dapat menggunakan perintah az ad sp show. Tentukan ID Aplikasi sebagai parameter. Berikut adalah contoh mendapatkan OID untuk perwakilan layanan yang sesuai dengan pendaftaran aplikasi dengan ID Aplikasi = ffffffff-eeee-dddd-cc-bbbbbbbbbbb0. Jalankan perintah berikut di Azure CLI:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

OID akan ditampilkan.

Ketika Anda memiliki OID yang benar untuk perwakilan layanan, buka halaman Kelola Akses Penjelajah Penyimpanan untuk menambahkan OID dan tetapkan izin yang sesuai untuk OID. Pastikan Anda memilih Simpan

Bisakah saya mengatur ACL kontainer?

Tidak. Kontainer tidak memiliki ACL. Namun, Anda dapat mengatur ACL direktori akar kontainer. Setiap kontainer memiliki direktori akar, dan memiliki nama yang sama dengan kontainer. Misalnya, jika kontainer diberi nama my-container, maka direktori akar diberi nama my-container/.

Azure Storage REST API memang berisi operasi bernama Set Container ACL, tetapi operasi tersebut tidak dapat digunakan untuk mengatur ACL kontainer atau direktori akar kontainer. Sebagai gantinya, operasi tersebut digunakan untuk menunjukkan apakah blob dalam kontainer dapat diakses dengan permintaan anonim. Sebaiknya minta otorisasi untuk semua permintaan ke data blob. Untuk informasi selengkapnya, lihat Gambaran Umum: Memulihkan akses baca anonim untuk data blob.

Di mana saya dapat mempelajari selengkapnya tentang model kontrol akses POSIX?

Lihat juga