Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pagar pembatas tambahan
Ketika permintaan presigned digunakan dengan tepat oleh pembuat solusi dan pengguna, mereka menyediakan mekanisme yang aman untuk memberikan pengguna akses ke data. Selain itu, kemampuan untuk menghasilkan permintaan yang telah ditetapkan sebelumnya tidak memberikan akses kepada prinsipal yang belum mereka miliki.
Dalam konteks itu, apakah kontrol tambahan diperlukan? Pembenaran untuk kontrol tambahan tidak didasarkan pada kebutuhan untuk menolak akses tetapi untuk menyediakan kemampuan untuk memantau, untuk menyetujui penggunaan dan menetapkan batasan, dan untuk mengurangi risiko dari kesalahan pengguna. Dengan cara ini Anda dapat membantu memastikan bahwa penggunaan sesuai dan perlu.
Pagar pembatas berikut membantu Anda dalam tujuan ini. Sebelum mengaktifkan kontrol ini, Anda mungkin ingin menentukan penggunaan yang ada dengan mengidentifikasi permintaan yang telah ditetapkan sebelumnya. Identifikasi ini membantu Anda mempersiapkan dampak pagar pembatas terhadap penggunaan yang ada atau merencanakan pengecualian jika diperlukan.
Pagar pembatas untuk S3: SignatureAge
Salah satu karakteristik yang menentukan dari permintaan yang telah ditetapkan sebelumnya adalah bahwa mereka menggambarkan waktu kedaluwarsa. Tanda tangan untuk permintaan berisi tanggal. Tanggal ini ditransmisikan sebagai parameter string X-Amz-Date kueri untuk presigned URLs, dan sebagai Tanggal atau x-amz-date header untuk POST presigned.
Amazon S3 menyediakan kunci kondisi, S3:SignatureAge, yang dapat Anda gunakan untuk membatasi waktu maksimum antara tanggal yang ditandatangani dan kedaluwarsa efektif permintaan. Kondisi ini tidak pernah dapat meningkatkan masa berlaku, tetapi dapat menguranginya.
Dalam kebijakan berikut, kunci s3:signatureAge kondisi membatasi permintaan yang telah ditetapkan sebelumnya hingga 15 menit validitas. Contoh berikut semua menggunakan 15 menit untuk membatasi validitas untuk jangka waktu yang sama sebagai dukungan penandatanganan standar.
Pernyataan kedua dari kebijakan tersebut menolak akses Signature Version 2. Versi protokol penandatanganan ini tidak digunakan lagi, tetapi masih didukung di beberapa. Wilayah AWS Kami menyarankan Anda memblokirnya secara eksplisit sebelum sepenuhnya tidak digunakan lagi.
Anda dapat menerapkan kebijakan berikut sebagai kebijakan kontrol AWS Organizations layanan (SCP). Pengguna masih dapat menggunakan permintaan yang telah ditetapkan sebelumnya dan menerapkan solusi yang bergantung pada permintaan tersebut, selama waktu antara pembuatan tanda tangan dan penggunaan kurang dari 15 menit. Bergantung pada implementasinya, batasan ini mungkin tidak berdampak, dapat menyebabkan solusi menjadi tidak dapat digunakan, atau mungkin menyebabkan kegagalan sesekali yang dapat dicoba ulang.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" } } }, { "Sid": "DenySignatureVersion2", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringEquals": { "s3:signatureversion": "AWS" } } } ] }
Pengecualian
Jika solusi memerlukan waktu yang lebih lama sebelum kedaluwarsa dan oleh karena itu dipengaruhi oleh kebijakan sebelumnya, kami sarankan Anda menyediakan metode untuk menyetujui pengecualian. Untuk menghindari penghitungan pengecualian dalam SCP, gunakan aws:, seperti dalam kebijakan berikutPrincipalTag, untuk mengelola pengecualian dengan cara yang dapat diskalakan. AWS Contoh lain, seperti contoh kebijakan perimeter data AWS
Jika Anda menerapkan kebijakan pengecualian dengan menggunakanaws:PrincipalTag, Anda harus mengontrol akses untuk menyetel tag pada prinsipal. Tag jenis ini dapat datang langsung dari prinsipal dan dapat dikontrol oleh SCP, seperti dalam contoh pengendalian nilai tag mana yangaws:PrincipalTag adalah topik yang kompleks. Namun, organisasi yang memiliki pengalaman dalam menggunakan kontrol akses berbasis atribut (ABAC) akan memiliki pengalaman dan kontrol untuk memungkinkan penggunaan yang tepat aws:PrincipalTag untuk kasus penggunaan ini.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, --- Example exception --- "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } --- Example exception end --- } } ] }
Kebijakan bucket
Anda dapat menerapkan kebijakan bucket ke semua atau bucket yang dipilih dengan menggunakan kebijakan seperti pada contoh berikut. Tidak seperti SCP, kebijakan bucket juga menargetkan penggunaan utama layanan. Lampiran A tidak mendokumentasikan penggunaan utama layanan yang diharapkan dari permintaan yang telah ditetapkan sebelumnya, tetapi jika Anda ingin menerapkan kontrol untuk membuktikan batas tersebut, kebijakan berikut akan memberikan kontrol tersebut. Selain itu, tidak seperti SCP, kebijakan bucket dapat berlaku untuk prinsipal di akun manajemen Anda. Pengecualian berbasis ABAC bekerja dalam kebijakan bucket dengan cara yang sama seperti SCP.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, --- Example exception --- "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } --- Example exception end --- } } ] }
Guardrail untuk S3:AuthType
Presigned URLs menggunakan otentikasi string kueri, dan presigned POSTs selalu menggunakan otentikasi POST. Amazon S3 mendukung penolakan permintaan berdasarkan jenis otentikasi melalui kunci kondisi S3:authType. REST-QUERY-STRINGadalah s3:authType nilai untuk string kueri, dan POST merupakan s3:authType nilai untuk POST.
Anda dapat menerapkan kebijakan berikut sebagai SCP. Kebijakan ini digunakan s3:authType untuk mengizinkan hanya autentikasi berbasis header. Ini juga mengkonfigurasi metode untuk memberikan pengecualian kepada pengguna individu atau peran.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Menolak permintaan berdasarkan jenis otentikasi memengaruhi solusi atau fitur apa pun yang menggunakan jenis otentikasi yang ditolak. Misalnya, menyangkal REST-QUERY-STRING mencegah pengguna melakukan unggahan atau unduhan dari konsol Amazon S3. Jika Anda ingin pengguna menggunakan konsol Amazon S3, jangan gunakan pagar pembatas ini, atau buat pengecualian untuk pengguna. Di sisi lain, jika Anda tidak ingin pengguna menggunakan konsol Amazon S3, Anda dapat menolak REST-QUERY-STRING untuk pengguna.
Mungkin Anda sudah menolak akses langsung pengguna ke sumber daya Amazon S3. Dalam hal ini, pagar pembatas untuk jenis otentikasi berlebihan. Namun, pernyataan s3:authType penolakan menyediakan defense-in-depth utilitas karena implementasi untuk menolak akses langsung biasanya mencakup banyak pernyataan kontrol, beberapa dengan pengecualian.
Peran yang digunakan untuk beban kerja biasanya tidak memerlukan akses ke string kueri atau POST otentikasi. Pengecualian adalah peran yang mendukung layanan yang dirancang untuk menggunakan permintaan yang telah ditetapkan sebelumnya. Anda dapat membuat pengecualian khusus untuk peran tersebut.
Anda juga dapat menerapkan kebijakan bucket ke semua atau bucket yang dipilih dengan menggunakan kebijakan seperti berikut:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
Kebijakan bucket ini memiliki efek menolak penggunaan CopyObjectdan UploadPartCopy APIs untuk membuat salinan lintas wilayah. Replikasi Amazon S3 tidak terpengaruh karena tidak bergantung pada ini. APIs
Jika Anda ingin menggunakan kebijakan bucket seperti kebijakan sebelumnya dan masih mendukung Cross-region CopyObjectatau UploadPartCopyAPI, tambahkan kondisi yang aws:ViaAWSService serupa dengan berikut ini:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" }, "Bool": { "aws:ViaAWSService": "false" }, } } ] }
Menggabungkan pagar pembatas dan pengecualian untuk pagar pembatas lainnya
Jika Anda tidak berencana untuk menerapkan pagar pembatas secara umum kepada pengguna dan peran Anda, Anda mungkin ingin menerapkannya pada pengecualian pagar pembatas umum lainnya, sehingga pengecualian tersebut tidak mendukung permintaan yang telah ditetapkan sebelumnya.
Jika Anda memiliki batasan jaringan tetapi mengizinkan pengecualian untuk mitra eksternal atau kasus penggunaan khusus, Anda harus memblokir string kueri atau POST otentikasi saat pengecualian tersebut diterapkan, kecuali jika secara khusus diidentifikasi sebagai diperlukan.
Batasan untuk S3: SignatureAge
Administrator akan merasa berguna untuk memahami implikasi s3:signatureAge lebih lengkap. Setiap permintaan yang ditandatangani termasukX-Amz-Date, yang harus menunjukkan waktu saat ini. Nilai ini diisi oleh klien dan penandatangan permintaan. AWS menolak permintaan yang dianggap memiliki waktu yang tidak valid. Namun, seorang penandatangan dapat menghasilkan tanda tangan terlebih dahulu dengan waktu yang akan datang. Amazon S3 menolak permintaan yang menentukan masa depan jika dikirim terlalu jauh sebelumnya. Namun, jika permintaan tidak dikirim sampai waktu yang ditandatangani ke tanda tangan, tanda tangan dapat dibuat lebih awal dan dikirim kemudian.
s3:signatureAgemembatasi usia maksimum X-Amz-Date dalam tanda tangan hanya untuk permintaan yang telah ditetapkan sebelumnya. Permintaan yang lebih tua dari usia yang ditentukan ditolak, bahkan jika kedaluwarsa X-Amz-Expires atau POST kebijakan akan menyatakannya valid. s3:signatureAgetidak mengubah periode valid untuk permintaan yang tidak menyertakan kedaluwarsa eksplisit. Itu juga tidak mengontrol nilai X-Amz-Date yang digunakan klien untuk tanda tangan.
Jika jam sistem salah atau jika klien sengaja melakukan permintaan tanggal di masa depan, waktu yang ditandatangani mungkin bukan waktu tanda tangan dibuat. Ini membatasi seberapa banyak yang s3:signatureAge dapat mengontrol solusi. Solusi yang menggunakan waktu saat ini ketika menghasilkan tanda tangan dibatasi dengan cara yang diharapkan: Tanda tangan tetap valid untuk jumlah milidetik yang ditentukan dalam. s3:signatureAge Solusi yang tidak menggunakan waktu saat ini akan memiliki batas yang berbeda. Salah satu batasan adalah bahwa kredensil yang digunakan untuk menandatangani tanda tangan harus tetap valid. Sebagai administrator, Anda dapat mengontrol validitas maksimum kredenal sementara yang dikeluarkan. Anda dapat mengizinkan kredensialnya valid hingga 36 jam atau membatasi validitas hingga serendah 15 menit. Berakhirnya kredensi sementara tidak tergantung pada nilai. X-Amz-Date
Kredensi permanen tidak memiliki batasan ini. Hanya menggunakan kredensil sementara adalah praktik terbaik, dan Anda dapat secara eksplisit mencabut kredensi permanen apa pun, yang juga akan membatalkan tanda tangan apa pun berdasarkan kredensi tersebut.
Meskipun s3:signatureAge diukur dalam milidetik, tidak praktis untuk mengaturnya menjadi kurang dari 60 detik, bahkan jika Anda memiliki jam yang disinkronkan dengan baik dan penggunaan latensi rendah. Pengaturan yang lebih rendah dari 60 detik berisiko menolak permintaan yang valid. Jika Anda mengharapkan penundaan antara pembuatan tanda tangan dan pengiriman permintaan, atau masalah dengan sinkronisasi jam, Anda harus memperhitungkannya dalam pengelolaan. s3:signatureAge
Menargetkan ember dalam skala
SCPs dapat digunakan aws:PrincipalTag untuk membuat pengecualian bagi pengguna. Anda tidak dapat menggunakan tag pada bucket untuk mengontrol akses melalui aws:ResourceTag ― hanya tag objek yang digunakan untuk kontrol akses. Umumnya tidak dapat diskalakan untuk menambahkan tag ke setiap objek yang ingin Anda terapkan kontrol ini.
Solusi yang sesuai dengan banyak kasus penggunaan adalah dengan menerapkan kebijakan dan pengecualian di tingkat akun, baik dengan mengubah akun yang diterapkan SCP atau dengan menggunakan aws:ResourceAccount, aws: ResourceOrgPaths, atau aws: ResourceOrg ID. Misalnya, SCP dapat diterapkan ke satu set akun produksi.
Solusi lain adalah dengan menggunakan AWS Config aturan khusus untuk menerapkan kontrol detektif atau kontrol responsif. Tujuannya adalah agar setiap ember berisi kebijakan ember dengan pagar pembatas yang sesuai. Selain menguji konten kebijakan bucket, AWS Config aturan kustom dapat mengambil tag dari bucket dan mengecualikan bucket dari aturan jika bucket diberi tag dengan nilai tertentu. Jika aturan itu gagal dalam pemeriksaan kepatuhannya, aturan tersebut dapat menandai bucket sebagai tidak sesuai atau meminta perbaikan untuk menambahkan pagar pembatas ke kebijakan bucket.
catatan
Anda tidak dapat membatasi konten tag permintaan. PutBucketTagging Untuk mempertahankan kontrol atas bagaimana bucket ditandai, Anda harus membatasi akses ke PutBucketTagging dan DeleteBucketTagging.
