External ID dan Deputi yang Bingung

Ketika Anda mengizinkan pihak ketiga mengambil peran di akun Anda, risiko keamanan yang disebut masalah deputi yang bingung dapat muncul. ID eksternal adalah kontrol sederhana tetapi penting untuk mencegahnya. Pola ini muncul dalam ujian setiap kali vendor SaaS memerlukan akses ke akun AWS Anda.

Deputi yang bingung adalah entitas tepercaya (deputi) yang ditipu sehingga menggunakan kewenangannya untuk kepentingan penyerang. Di AWS, layanan pihak ketiga memiliki izin untuk mengambil peran di banyak akun pelanggan; penyerang dapat menipunya agar mengambil peran Anda jika tidak ada hal yang mengaitkan permintaan tersebut dengan hubungan pelanggan yang sah.

Bayangkan sebuah SaaS pemantauan yang mengambil peran di setiap akun pelanggan. SaaS tersebut menggunakan satu identitas AWS untuk semua pelanggan. Jika penyerang yang juga merupakan pelanggan menebak ARN peran Anda, mereka mungkin dapat membujuk SaaS tersebut untuk mengambil peran Anda, karena SaaS adalah principal tepercaya. ID akun saja tidak cukup untuk mencegah hal ini.

ID eksternal adalah nilai unik dan rahasia yang ditetapkan vendor untuk hubungan Anda. Anda memasukkannya ke dalam kebijakan kepercayaan peran sebagai kondisi, dan vendor harus memberikan nilai yang sama persis saat memanggil AssumeRole. Karena penyerang tidak mengetahui ID eksternal Anda, mereka tidak dapat menipu vendor agar mengambil peran Anda.

Kebijakan kepercayaan ini mewajibkan ID eksternal yang sesuai. AssumeRole hanya berhasil jika vendor meneruskan nilai yang identik, sehingga serangan deputi yang bingung dapat digagalkan.

Yang penting, vendor yang membuat dan mengendalikan ID eksternal, bukan pelanggan. Hal ini mencegah pelanggan berkolusi untuk menggunakan kembali nilai yang sama. Panduan AWS sudah jelas: sebagai pihak ketiga, Anda harus menetapkan ID eksternal unik untuk setiap pelanggan dan mewajibkannya pada setiap pengambilan peran.

ID eksternal tidak dimaksudkan untuk menjadi rahasia seperti kata sandi; ID ini dapat muncul dalam petunjuk penyiapan. Nilai keamanannya berasal dari sifatnya yang unik untuk setiap pelanggan dan dikendalikan oleh vendor, sehingga penyerang tidak dapat membuat deputi menggunakan nilai milik pelanggan lain. Perlakukan ID ini sebagai token antipenyamaran, bukan kredensial.

ID eksternal mengendalikan siapa yang dapat mengambil peran, tetapi Anda tetap harus membatasi apa yang dapat dilakukan peran tersebut dengan kebijakan izin yang ketat. Bahkan vendor yang telah diberi wewenang dengan benar hanya boleh menerima izin minimum yang diperlukan. Gabungkan ID eksternal, principal tertentu, dan izin dengan hak akses minimum untuk akses pihak ketiga yang aman.

Pola deputi yang bingung juga berlaku untuk layanan AWS yang bertindak atas nama Anda. Kepercayaan antarlayanan sering menggunakan kunci kondisi seperti aws:SourceArn dan aws:SourceAccount dalam kebijakan sumber daya untuk memastikan layanan pemanggil bertindak untuk sumber daya Anda; ini adalah gagasan pertahanan yang sama dalam bentuk berbeda.

Setiap kali pertanyaan menjelaskan pihak ketiga atau SaaS yang mengambil peran lintas akun, jawaban aman hampir selalu melibatkan ID eksternal dalam kebijakan kepercayaan. Jika skenarionya adalah komunikasi antarlayanan, carilah kondisi aws:SourceArn/aws:SourceAccount. Mengenali petunjuk ini akan langsung mengarahkan Anda ke kontrol yang tepat.

Masalah deputi yang bingung memungkinkan penyerang menipu pihak ketiga tepercaya agar menyalahgunakan aksesnya. ID eksternal, yang unik untuk setiap pelanggan dan dikendalikan oleh vendor, mencegahnya dengan mewajibkan nilai yang sesuai pada AssumeRole. Untuk layanan AWS, gunakan aws:SourceArn dan aws:SourceAccount. Selalu gabungkan semua ini dengan izin hak akses minimum.

Uji pemahaman Anda tentang konsep deputi yang bingung.

Masalah deputi yang bingung muncul ketika pihak ketiga tepercaya ditipu sehingga menyalahgunakan akses lintas akunnya. ID eksternal, yang unik untuk setiap pelanggan dan dikendalikan oleh vendor, mencegahnya melalui kondisi kebijakan kepercayaan pada sts:ExternalId. Untuk kepercayaan antarlayanan AWS, gunakan aws:SourceArn dan aws:SourceAccount, selalu dengan hak akses minimum.