Otorisasi Object Storage Service (OSS) memverifikasi permintaan untuk memberikan atau menolak akses. Dalam mengambil keputusan, OSS mengevaluasi jenis permintaan, informasi identitas, dan kebijakan izin yang berlaku.
Cara kerja
Jenis permintaan
OSS mengklasifikasikan permintaan akses menjadi dua jenis berdasarkan ada tidaknya informasi identitas dalam permintaan tersebut:
Jenis permintaan | Deskripsi |
permintaan non-anonim | Berisi informasi terkait identitas, seperti signature, dalam header permintaan atau URL. |
permintaan anonim | Tidak berisi informasi identitas apa pun dalam header permintaan atau URL. |
Prinsip otorisasi
Otorisasi OSS mengikuti prinsip bahwa penolakan eksplisit memiliki prioritas lebih tinggi. Permintaan dievaluasi dengan urutan prioritas sebagai berikut:
Deny Eksplisit (Prioritas tertinggi): Jika permintaan sesuai dengan aturan deny, OSS segera menolaknya.
Allow: Jika tidak ada aturan deny yang sesuai dan terdapat aturan allow yang sesuai, OSS mengizinkan permintaan tersebut.
Deny Implisit (Default): Jika tidak ada aturan yang sesuai, OSS secara default menolak permintaan tersebut.
Alur otorisasi untuk permintaan non-anonim
Permintaan non-anonim menjalani otorisasi multi-lapis, termasuk Control Policy (jika berlaku), autentikasi, session policy, RAM policy, bucket policy, dan ACL.
Langkah-langkah detail alur otorisasi adalah sebagai berikut:
Autentikasi: OSS mengautentikasi permintaan dengan membandingkan signature dalam permintaan dengan signature yang dihitung oleh server OSS.
Tidak cocok: Permintaan ditolak.
Cocok: Proses dilanjutkan ke langkah berikutnya.
Periksa Control Policy: OSS memeriksa apakah akun Alibaba Cloud pemilik resource termasuk dalam resource directory (RD) dan memiliki Control Policy yang diaktifkan.
Tidak (Akun bukan anggota RD, atau merupakan anggota RD tetapi Control Policy tidak diaktifkan): Proses dilanjutkan ke langkah berikutnya.
Ya (Akun merupakan anggota RD dan Control Policy diaktifkan): OSS mengevaluasi Control Policy. Jika hasilnya deny eksplisit atau deny implisit, permintaan ditolak. Jika hasilnya allow, proses dilanjutkan.
Periksa session policy: OSS menentukan apakah permintaan menggunakan session policy berbasis role.
Ya: OSS mengevaluasi session policy. Jika hasilnya deny eksplisit atau deny implisit, permintaan ditolak. Jika hasilnya allow, proses dilanjutkan.
Tidak: Langkah ini dilewati, dan proses dilanjutkan.
Periksa RAM policy dan bucket policy: OSS mengevaluasi kedua jenis kebijakan secara terpisah dan menggabungkan hasilnya.
RAM policy: Kebijakan berbasis identitas yang mengontrol resource mana yang dapat diakses oleh RAM user. Untuk akses tingkat pengguna, OSS menentukan hasil otorisasi berdasarkan jenis akun yang mengirim permintaan:
AccessKey akun Alibaba Cloud: Hasilnya adalah deny implisit.
AccessKey RAM user atau AccessKey STS: Jika bucket tidak dimiliki oleh akun Alibaba Cloud yang memiliki RAM user atau RAM role tersebut, hasilnya adalah deny implisit. Jika tidak, RAM mengotorisasi permintaan dan mengembalikan allow, deny eksplisit, atau deny implisit.
bucket policy: Ini adalah kebijakan berbasis resource yang mengontrol akses ke bucket atau resource di dalamnya.
Tidak ada kebijakan yang dikonfigurasi: Hasilnya adalah deny implisit.
Kebijakan dikonfigurasi: Hasilnya adalah allow, deny eksplisit, atau deny implisit.
Evaluasi hasil gabungan: OSS membuat keputusan berdasarkan hasil gabungan dari RAM policy dan bucket policy.
Jika hasil gabungan berisi deny eksplisit, permintaan ditolak.
Jika hasil gabungan berisi allow, permintaan diizinkan.
Jika kedua hasil adalah deny implisit, proses dilanjutkan ke langkah berikutnya.
Periksa jenis API: Jenis API menentukan langkah selanjutnya.
Management API (seperti
GetService,PutBucket, danPutLiveChannel): Permintaan ditolak.Data API (seperti
PutObjectdanGetObject): Proses dilanjutkan ke evaluasi ACL.
Periksa object ACL dan bucket ACL: OSS mengizinkan atau menolak permintaan berdasarkan hasil evaluasi.
Saat mengevaluasi object ACL, OSS mempertimbangkan apakah pemohon adalah pemilik bucket dan jenis permintaan (baca atau tulis).
Jika object ACL diatur untuk mewarisi dari bucket, OSS melanjutkan evaluasi bucket ACL. Saat mengevaluasi bucket ACL, OSS juga mempertimbangkan apakah pemohon adalah pemilik bucket.
Alur otorisasi untuk permintaan anonim
Permintaan anonim melewati pemeriksaan Control Policy (jika berlaku), autentikasi, dan RAM policy. OSS mengotorisasi permintaan tersebut hanya berdasarkan bucket policy dan ACL.
Langkah-langkah detail alur otorisasi adalah sebagai berikut:
Periksa bucket policy:
Deny: Permintaan ditolak.
Allow: Permintaan diizinkan.
Abaikan (tidak ada kebijakan yang dikonfigurasi atau tidak ada aturan yang sesuai): Proses dilanjutkan ke langkah berikutnya.
Periksa object ACL dan bucket ACL:
Jika object ACL bersifat private: Permintaan ditolak.
Jika object ACL bersifat public-read atau public-read-write: Permintaan diizinkan.
Jika object ACL diatur untuk mewarisi dari bucket: OSS melanjutkan evaluasi bucket ACL.
Jika bucket ACL bersifat public-read atau public-read-write: Permintaan diizinkan.
Jika bucket ACL bersifat private: Permintaan ditolak.