Ikhtisar URL yang telah ditetapkan sebelumnya

URL presigned adalah jenis permintaan HTTP yang dikenali oleh layanan AWS Identity and Access Management (IAM). Yang membedakan jenis permintaan ini dari semua AWS permintaan lainnya adalah parameter kueri X-Amz-Expires. Seperti permintaan otentikasi lainnya, permintaan URL presigned menyertakan tanda tangan. Untuk permintaan URL yang telah ditetapkan sebelumnya, tanda tangan ini dikirimkanX-Amz-Signature. Tanda tangan menggunakan operasi kriptografi Signature Version 4 untuk menyandikan semua parameter permintaan lainnya.

Catatan

• Signature Version 2 saat ini sedang dalam proses tidak digunakan lagi, tetapi masih didukung di beberapa. Wilayah AWS Panduan ini berlaku untuk penandatanganan Signature Version 4.

• Layanan penerima dapat memproses header yang tidak ditandatangani, tetapi dukungan untuk opsi itu terbatas dan ditargetkan, sejalan dengan praktik terbaik. Kecuali dinyatakan lain, asumsikan bahwa semua header harus ditandatangani agar permintaan diterima.

X-Amz-ExpiresParameter memungkinkan tanda tangan diproses sebagai valid dengan penyimpangan yang lebih besar dari waktu tanggal yang dikodekan. Aspek lain dari validitas tanda tangan masih dievaluasi. Kredensi penandatanganan, jika sementara, tidak boleh kedaluwarsa pada saat tanda tangan diproses. Kredensi penandatanganan harus dilampirkan pada kepala sekolah IAM yang memiliki otorisasi yang memadai pada saat pemrosesan.

URL yang telah ditetapkan sebelumnya adalah bagian dari permintaan yang telah ditetapkan sebelumnya

URL presigned bukan satu-satunya metode untuk menandatangani permintaan untuk masa depan. Amazon S3 juga mendukung permintaan POST, yang biasanya juga sudah ditentukan sebelumnya. Tanda tangan POST yang telah ditetapkan sebelumnya memungkinkan unggahan yang mematuhi kebijakan yang ditandatangani dan memiliki tanggal kedaluwarsa yang disematkan dalam kebijakan tersebut.

Tanda tangan untuk permintaan dapat diberi tanggal di masa mendatang, meskipun ini jarang terjadi. Selama kredensyal yang mendasarinya valid, algoritma tanda tangan tidak melarang penanggalan masa depan. Namun, permintaan ini tidak dapat berhasil diproses sampai jendela waktu yang valid, yang membuat kencan future tidak praktis untuk sebagian besar kasus penggunaan.

Apa yang diizinkan oleh permintaan yang telah ditetapkan sebelumnya?

Permintaan presigned hanya dapat mengizinkan tindakan yang diizinkan oleh kredensyal yang digunakan untuk menandatangani permintaan. Jika kredensyal secara implisit atau eksplisit menolak tindakan yang ditentukan oleh permintaan yang telah ditetapkan sebelumnya, permintaan yang telah ditetapkan sebelumnya akan ditolak saat dikirim. Ini berlaku untuk yang berikut:

• Kebijakan sesi yang terkait dengan kredensialnya

• Kebijakan yang terkait dengan kepala sekolah yang terkait dengan kredensialnya

• Kebijakan sumber daya yang memengaruhi sesi atau prinsipal

• Kebijakan pengendalian layanan yang memengaruhi sesi atau prinsipal

Motivasi untuk menggunakan permintaan yang telah ditentukan sebelumnya

Sebagai insinyur keamanan, Anda harus menyadari apa yang memotivasi pembuat solusi untuk menggunakan URL yang telah ditetapkan sebelumnya. Memahami apa yang diperlukan dan apa yang opsional akan membantu Anda berkomunikasi dengan pembuat solusi. Motivasi mungkin termasuk yang berikut:

• Untuk mendukung mekanisme otentikasi non-IAM sambil memanfaatkan skalabilitas di Amazon S3. Motivasi inti adalah berkomunikasi langsung dengan Amazon S3 untuk mendapatkan manfaat dari skalabilitas bawaan yang disediakan oleh layanan ini. Tanpa komunikasi langsung ini, solusi perlu mendukung beban dari transmisi ulang byte yang dikirim dan panggilan. PutObjectGetObject Bergantung pada beban total, persyaratan ini menambahkan tantangan penskalaan yang mungkin ingin dihindari oleh pembuat solusi.

  Cara lain untuk berkomunikasi langsung dengan Amazon S3, seperti menggunakan kredensyal sementara AWS Security Token Service di AWS STS() atau tanda tangan Versi Tanda Tangan 4 di luar URL, mungkin tidak sesuai untuk kasus penggunaan Anda. Amazon S3 mengidentifikasi pengguna melalui AWS kredensyal, sedangkan permintaan presigned mengandaikan identifikasi melalui mekanisme selain kredensyal. AWS Menjembatani perbedaan ini sambil mempertahankan komunikasi langsung untuk data dapat dicapai melalui permintaan yang telah ditentukan sebelumnya.

• Untuk mendapatkan manfaat dari pemahaman asli browser tentang URL. URL dipahami oleh browser, sedangkan AWS STS kredensyal dan tanda tangan Versi Tanda Tangan 4 tidak. Ini bermanfaat saat berintegrasi dengan solusi berbasis browser. Solusi alternatif memerlukan lebih banyak kode, akan menggunakan lebih banyak memori untuk file besar, dan mungkin diperlakukan berbeda dengan ekstensi seperti malware dan pemindai virus.

Perbandingan dengan AWS STS kredensyal sementara

Kredensyal sementara mirip dengan permintaan yang telah ditetapkan sebelumnya. Keduanya kedaluwarsa, memungkinkan pelingkupan akses, dan biasanya digunakan untuk menjembatani kredensyal non-IAM dengan penggunaan yang memerlukan kredensyal AWS. 

Anda dapat secara ketat mencakup AWS STS kredensi sementara ke satu objek dan tindakan S3, tetapi ini dapat menghasilkan tantangan penskalaan karena AWS STS API memiliki batasan. (Untuk informasi selengkapnya, lihat artikel Bagaimana cara mengatasi pelambatan API atau kesalahan “Nilai terlampaui” untuk IAM dan di situs web AWS AWS STS re:Post.) Selain itu, setiap kredensi yang dihasilkan memerlukan panggilan AWS STS API, yang menambahkan latensi dan ketergantungan baru yang dapat memengaruhi ketahanan. AWS STS Kredensyal sementara juga memiliki waktu kedaluwarsa minimum 15 menit, sedangkan permintaan yang telah ditentukan sebelumnya dapat mendukung durasi yang lebih pendek. (60 detik praktis mengingat kondisi yang tepat.)

Perbandingan dengan solusi khusus tanda tangan

Satu-satunya komponen rahasia inheren dari permintaan yang telah ditetapkan sebelumnya adalah tanda tangan Versi Tanda Tangan 4. Jika klien mengetahui detail lain dari permintaan dan diberikan tanda tangan yang valid yang cocok dengan detail tersebut, ia dapat mengirim permintaan yang valid. Tanpa tanda tangan yang valid, tidak bisa.

URL yang telah ditetapkan sebelumnya dan solusi khusus tanda tangan serupa secara kriptografis. Namun, solusi khusus tanda tangan memiliki keuntungan praktis seperti kemampuan untuk menggunakan header HTTP alih-alih parameter string kueri untuk mengirimkan tanda tangan (lihat bagian Interaksi dan mitigasi Logging). Administrator juga harus mempertimbangkan bahwa string kueri lebih sering diperlakukan sebagai metadata, sedangkan header lebih jarang diperlakukan seperti itu.

Di sisi lain, AWS SDK memberikan lebih sedikit dukungan untuk menghasilkan dan menggunakan tanda tangan secara langsung. Membangun solusi khusus tanda tangan memerlukan lebih banyak kode khusus. Dari perspektif praktis, menggunakan pustaka alih-alih kode khusus untuk keamanan adalah praktik terbaik umum, sehingga kode untuk solusi khusus tanda tangan memerlukan pengawasan ekstra.

Solusi khusus tanda tangan tidak menggunakan string X-Amz-Expires kueri dan tidak memberikan periode validitas eksplisit. IAM mengelola periode validitas implisit tanda tangan yang tidak memiliki waktu kedaluwarsa eksplisit. Periode implisit tersebut tidak dipublikasikan. Mereka biasanya tidak berubah, tetapi dikelola dengan mempertimbangkan keamanan, jadi Anda tidak boleh bergantung pada periode validitas. Ada tradeoff antara memiliki kontrol eksplisit atas tanggal kedaluwarsa dan meminta IAM mengelola kedaluwarsa.

Sebagai administrator, Anda mungkin lebih memilih solusi khusus tanda tangan. Namun, dalam arti praktis, Anda harus mendukung solusi seperti yang dibangun.