Masalah confused deputy

Masalah deputi yang bingung adalah masalah keamanan di mana entitas yang tidak memiliki izin untuk melakukan tindakan dapat memaksa entitas yang lebih istimewa untuk melakukan tindakan. Untuk mencegah hal ini, AWS sediakan alat yang membantu Anda melindungi akun Anda jika Anda memberi pihak ketiga (dikenal sebagai lintas akun) atau AWS layanan lain (dikenal sebagai lintas layanan) akses ke sumber daya di akun Anda.

Terkadang, Anda mungkin perlu memberi pihak ketiga akses ke AWS sumber daya Anda (akses delegasi). Misalnya, katakanlah Anda memutuskan untuk menyewa perusahaan pihak ketiga bernama Example Corp untuk memantau Anda Akun AWS dan membantu mengoptimalkan biaya. Untuk melacak pengeluaran harian Anda, Example Corp perlu mengakses AWS sumber daya Anda. Contoh Corp juga memantau banyak lainnya Akun AWS untuk pelanggan lain. Anda dapat menggunakan peran IAM untuk membangun hubungan tepercaya antara akun Anda Akun AWS dan akun Example Corp. Salah satu aspek penting dari skenario ini adalah ID eksternal, informasi opsional yang dapat Anda gunakan dalam kebijakan kepercayaan peran IAM untuk menentukan siapa yang dapat mengambil peran tersebut. Fungsi utama dari ID eksternal adalah mengatasi dan mencegah masalah deputi yang membingungkan.

Pada tahun AWS, peniruan lintas layanan dapat mengakibatkan masalah wakil yang membingungkan. Peniruan identitas lintas layanan dapat terjadi ketika satu layanan (layanan yang dipanggil) memanggil layanan lain (layanan yang dipanggil). Layanan pemanggilan dapat dimanipulasi menggunakan izinnya untuk bertindak pada sumber daya pelanggan lain dengan cara yang seharusnya tidak dilakukannya kecuali bila memiliki izin untuk mengakses.

Pencegahan Deputi Bingung Lintas Akun

Diagram berikut menggambarkan masalah wakil kebingungan lintas akun.

Skenario ini mengasumsikan hal berikut:

• AWS 1 adalah milikmu Akun AWS.

• AWS 1: ExampleRole adalah peran dalam akun Anda. Kebijakan kepercayaan peran ini mempercayai Example Corp dengan menentukan akun AWS Example Corp sebagai akun yang dapat mengambil peran tersebut.

Inilah yang terjadi:

1. Saat Anda mulai menggunakan layanan Example Corp, Anda memberikan ARN 1ExampleRole: ke AWS Example Corp.

2. Contoh Corp menggunakan peran ARN itu untuk mendapatkan kredenal keamanan sementara untuk mengakses sumber daya di Anda. Akun AWS Dengan cara ini, Anda mempercayai Example Corp sebagai “deputi” yang dapat bertindak atas nama Anda.

3. AWS Pelanggan lain juga mulai menggunakan layanan Example Corp, dan pelanggan ini juga menyediakan ARN 1ExampleRole: untuk AWS Example Corp untuk digunakan. Agaknya pelanggan lain belajar atau menebak AWS 1: ExampleRole, yang bukan rahasia.

4. Ketika pelanggan lain meminta Example Corp untuk mengakses AWS sumber daya di (apa yang diklaimnya) akunnya, Example Corp menggunakan AWS 1: ExampleRole untuk mengakses sumber daya di akun Anda.

Inilah cara pelanggan lain bisa mendapatkan akses tanpa izin ke sumber daya Anda. Karena pelanggan lain mampu mengelabui Example Corp untuk melakukan tindakan di luar kesadaran pada sumber daya Anda, Example Corp kini adalah “confused deputy.”

Contoh Corp dapat mengatasi masalah wakil yang membingungkan dengan mengharuskan Anda memasukkan pemeriksaan ExternalId kondisi dalam kebijakan kepercayaan peran. Contoh Corp menghasilkan ExternalId nilai unik untuk setiap pelanggan dan menggunakan nilai itu dalam permintaannya untuk mengambil peran tersebut. ExternalIdNilai harus unik di antara pelanggan Example Corp dan dikendalikan oleh Example Corp, bukan pelanggannya. Inilah mengapa Anda mendapatkannya dari Example Corp dan Anda tidak membuatnya sendiri. Ini mencegah Example Corp menjadi wakil yang bingung dan memberikan akses ke sumber daya akun lain. AWS

Dalam skenario kami, bayangkan pengenal unik Example Corp untuk Anda adalah 12345, dan pengenalnya untuk pelanggan lain adalah 67890. Pengidentifikasi ini disederhanakan untuk skenario ini. Umumnya, pengidentifikasi ini adalah GUID. Dengan asumsi pengidentifikasi ini bersifat unik di antara pelanggan Example Corp, mereka adalah nilai yang masuk akal untuk digunakan bagi ID eksternal.

Contoh Corp memberikan nilai ID eksternal 12345 kepada Anda. Anda kemudian harus menambahkan elemen Condition ke kebijakan kepercayaan peran yang memerlukan nilai sts:ExternalId 12345, seperti ini:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}

Elemen Kondisi dalam kebijakan ini memungkinkan Example Corp untuk mengambil peran hanya jika panggilan AssumeRole API menyertakan nilai ID eksternal 12345. Contoh Corp memastikan bahwa setiap kali mengambil peran atas nama pelanggan, selalu menyertakan nilai ID eksternal pelanggan tersebut AssumeRole dalam panggilan. Bahkan jika pelanggan lain memasok Example Corp dengan ARN Anda, ia tidak dapat mengontrol ID eksternal yang disertakan Example Corp dalam permintaannya. AWS Hal ini membantu mencegah pelanggan yang tidak berwenang untuk mendapatkan akses ke sumber daya Anda.

Diagram berikut menggambarkannya.

1. Seperti sebelumnya, ketika Anda mulai menggunakan layanan Example Corp, Anda memberikan ARN 1ExampleRole: ke AWS Example Corp.

2. Saat Example Corp menggunakan ARN peran itu untuk mengambil AWS peran 1 ExampleRole:, Example Corp menyertakan ID eksternal Anda (12345) dalam panggilan API. AssumeRole ID eksternal cocok dengan kebijakan kepercayaan peran, sehingga panggilan AssumeRole API berhasil dan Example Corp memperoleh kredensi keamanan sementara untuk mengakses sumber daya di file Anda. Akun AWS

3. AWS Pelanggan lain juga mulai menggunakan layanan Example Corp, dan seperti sebelumnya, pelanggan ini juga menyediakan ARN 1ExampleRole: untuk AWS Example Corp untuk digunakan.

4. Tapi kali ini, ketika Example Corp mencoba untuk mengambil peran AWS 1: ExampleRole, ia memberikan ID eksternal yang terkait dengan pelanggan lain (67890). Pelanggan lain tidak bisa mengubah ini. Contoh Corp melakukan ini karena permintaan untuk menggunakan peran berasal dari pelanggan lain, jadi 67890 menunjukkan keadaan di mana Example Corp bertindak. Karena Anda menambahkan kondisi dengan ID eksternal Anda sendiri (12345) ke kebijakan kepercayaan AWS 1: ExampleRole, panggilan AssumeRole API gagal. Pelanggan lain tidak bisa mendapatkan akses tanpa izin ke sumber daya dalam akun Anda (ditunjukkan oleh “X” merah di diagram).

ID eksternal membantu mencegah pelanggan lain menipu Example Corp agar tanpa disadari mengakses sumber daya Anda.

Pencegahan confused deputy lintas layanan

Sebaiknya gunakan kunci konteks kondisi aws:SourceArnaws:SourceAccountaws:SourceOrgID,, atau aws:SourceOrgPathsglobal dalam kebijakan berbasis sumber daya untuk membatasi izin yang dimiliki layanan ke sumber daya tertentu. Gunakan aws:SourceArn untuk mengaitkan hanya satu sumber daya dengan akses lintas layanan. Gunakan aws:SourceAccount untuk membiarkan sumber daya apa pun di akun itu dikaitkan dengan penggunaan lintas layanan. Gunakan aws:SourceOrgID untuk memungkinkan sumber daya apa pun dari akun apa pun dalam suatu organisasi dikaitkan dengan penggunaan lintas layanan. Gunakan aws:SourceOrgPaths untuk mengaitkan sumber daya apa pun dari akun dalam AWS Organizations jalur dengan penggunaan lintas layanan. Untuk informasi selengkapnya tentang menggunakan dan memahami jalur, lihat Memahami jalur AWS Organizations entitas.

Cara paling terperinci untuk melindungi dari masalah wakil yang membingungkan adalah dengan menggunakan kunci konteks kondisi aws:SourceArn global dengan ARN penuh sumber daya dalam kebijakan berbasis sumber daya Anda. Jika Anda tidak mengetahui ARN lengkap sumber daya atau jika Anda menentukan beberapa sumber daya, gunakan kunci konteks kondisi aws:SourceArn global dengan wildcard (*) untuk bagian ARN yang tidak diketahui. Misalnya, arn:aws:servicename:*:123456789012:*.

Jika aws:SourceArn nilainya tidak berisi ID akun, seperti ARN bucket Amazon S3, Anda harus menggunakan keduanya aws:SourceAccount dan aws:SourceArn untuk membatasi izin.

Untuk melindungi dari masalah wakil yang membingungkan dalam skala besar, gunakan aws:SourceOrgID atau kunci konteks kondisi aws:SourceOrgPaths global dengan ID organisasi atau jalur organisasi sumber daya dalam kebijakan berbasis sumber daya Anda. Kebijakan yang menyertakan aws:SourceOrgID atau aws:SourceOrgPaths kunci akan secara otomatis menyertakan akun yang benar dan Anda tidak perlu memperbarui kebijakan secara manual saat menambahkan, menghapus, atau memindahkan akun di organisasi Anda.

Untuk kebijakan kepercayaan non-service-linked peran, setiap layanan dalam kebijakan kepercayaan telah melakukan iam:PassRole tindakan untuk memverifikasi bahwa peran tersebut berada di akun yang sama dengan layanan panggilan. Akibatnya, menggunakan aws:SourceAccountaws:SourceOrgID, atau aws:SourceOrgPaths dengan kebijakan kepercayaan tersebut tidak diperlukan. Menggunakan aws:SourceArn dalam kebijakan kepercayaan memungkinkan Anda menentukan sumber daya peran yang dapat diasumsikan atas nama, seperti ARN fungsi Lambda. Beberapa kebijakan Layanan AWS penggunaan aws:SourceAccount dan aws:SourceArn kepercayaan untuk peran yang baru dibuat, tetapi menggunakan kunci tidak diperlukan untuk peran yang ada di akun Anda.

catatan

Layanan AWS yang terintegrasi dengan AWS Key Management Service menggunakan hibah kunci KMS tidak mendukung kunciaws:SourceArn,, aws:SourceAccountaws:SourceOrgID, atau aws:SourceOrgPaths kondisi. Penggunaan kunci kondisi ini dalam kebijakan kunci KMS akan menghasilkan perilaku yang tidak terduga jika kunci juga digunakan oleh Layanan AWS melalui hibah kunci KMS.

Pencegahan deputi kebingungan lintas layanan untuk AWS Security Token Service

Banyak AWS layanan mengharuskan Anda menggunakan peran untuk memungkinkan layanan mengakses sumber daya layanan lain atas nama Anda. Peran yang diasumsikan layanan untuk melakukan tindakan atas nama Anda disebut peran layanan. Peran memerlukan dua kebijakan: kebijakan kepercayaan peran yang menentukan prinsipal yang diizinkan untuk mengambil peran dan kebijakan izin yang menentukan apa yang dapat dilakukan dengan peran tersebut. Kebijakan kepercayaan peran adalah satu-satunya jenis kebijakan berbasis sumber daya di IAM. Lainnya Layanan AWS memiliki kebijakan berbasis sumber daya, seperti kebijakan bucket Amazon S3.

Ketika layanan mengambil peran atas nama Anda, kepala layanan harus diizinkan untuk melakukan sts:AssumeRoletindakan dalam kebijakan kepercayaan peran. Saat layanan memanggilsts:AssumeRole, AWS STS mengembalikan sekumpulan kredensial keamanan sementara yang digunakan prinsipal layanan untuk mengakses sumber daya yang diizinkan oleh kebijakan izin peran. Saat layanan mengambil peran di akun Anda, Anda dapat menyertakan kunci konteks kondisi aws:SourceArnaws:SourceAccount,aws:SourceOrgID, atau aws:SourceOrgPaths global dalam kebijakan kepercayaan peran Anda untuk membatasi akses ke peran hanya untuk permintaan yang dihasilkan oleh sumber daya yang diharapkan.

Misalnya, di AWS Systems Manager Incident Manager, Anda harus memilih peran untuk mengizinkan Manajer Insiden menjalankan dokumen otomatisasi Systems Manager atas nama Anda. Dokumen otomatisasi dapat mencakup rencana respons otomatis untuk insiden yang diprakarsai oleh CloudWatch alarm atau peristiwa. EventBridge Dalam contoh kebijakan kepercayaan peran berikut, Anda dapat menggunakan kunci aws:SourceArn kondisi untuk membatasi akses ke peran layanan berdasarkan ARN catatan insiden. Hanya catatan insiden yang dibuat dari sumber daya rencana respons myresponseplan yang dapat menggunakan peran ini.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "Service": "ssm-incidents.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*"
      }
    }
  }
}

catatan

Tidak semua integrasi layanan dengan AWS STS dukunganaws:SourceArn,, aws:SourceAccountaws:SourceOrgID, atau kunci aws:SourceOrgPaths kondisi. Penggunaan kunci ini dalam kebijakan kepercayaan IAM dengan integrasi yang tidak didukung dapat mengakibatkan perilaku yang tidak terduga.