Contoh kebijakan untuk mendelegasikan akses

Contoh berikut menunjukkan bagaimana Anda dapat mengizinkan atau memberikan Akun AWS akses ke sumber daya di tempat lain Akun AWS. Untuk mempelajari cara membuat IAM kebijakan menggunakan contoh dokumen JSON kebijakan ini, lihatMembuat kebijakan menggunakan JSON editor.

Menggunakan peran untuk mendelegasikan akses ke sumber daya orang lain Akun AWS sumber daya

Untuk tutorial yang menunjukkan cara menggunakan IAM peran untuk memberikan akses kepada pengguna dalam satu akun AWS sumber daya yang ada di akun lain, lihatIAMtutorial: Delegasikan akses di seluruh AWS akun menggunakan IAM peran.

penting

Anda dapat menyertakan peran atau pengguna tertentu dalam Principal elemen kebijakan kepercayaan peran. ARN Saat Anda menyimpan kebijakan, AWS mengubah menjadi ARN ID utama yang unik. Hal ini membantu memitigasi risiko seseorang meningkatkan hak istimewa mereka dengan menghapus dan membuat kembali peran atau pengguna. Anda biasanya tidak melihat ID ini di konsol, karena ada juga transformasi terbalik kembali ke ARN saat kebijakan kepercayaan ditampilkan. Namun, jika Anda menghapus peran atau pengguna, maka hubungan Anda akan rusak. Kebijakan tidak lagi berlaku, bahkan jika Anda membuat ulang pengguna atau peran karena itu tidak sesuai dengan ID prinsipal yang disimpan dalam kebijakan kepercayaan. Ketika ini terjadi, ID utama muncul di konsol karena AWS tidak bisa lagi memetakannya kembali ke fileARN. Hasilnya adalah jika Anda menghapus dan membuat ulang pengguna atau peran yang direferensikan dalam Principal elemen kebijakan kepercayaan, Anda harus mengedit peran tersebut untuk mengganti peran tersebut. ARN Itu diubah menjadi ID prinsipal baru saat Anda menyimpan kebijakan.

Menggunakan kebijakan untuk mendelegasikan akses ke layanan

Contoh berikut ini menunjukkan kebijakan yang dapat dilampirkan pada sebuah peran. Kebijakan ini memungkinkan dua layanan, Amazon EMR dan AWS Data Pipeline untuk mengambil peran. Layanan kemudian dapat melakukan tugas yang diberikan oleh kebijakan izin yang ditetapkan untuk peran tersebut (tidak ditampilkan). Untuk menetapkan beberapa prinsipal layanan, Anda tidak menentukan dua elemen Service; Anda hanya dapat memiliki satu. Sebagai gantinya, Anda menggunakan serangkaian dari beberapa prinsipal layanan sebagai nilai elemen Service tunggal.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Menggunakan kebijakan berbasis sumber daya untuk mendelegasikan akses ke bucket Amazon S3 di akun lain

Dalam contoh ini, akun A menggunakan kebijakan berbasis sumber daya (kebijakan bucket Amazon S3) untuk memberikan akun B akses penuh ke bucket S3 akun A. Kemudian akun B membuat kebijakan IAM pengguna untuk mendelegasikan akses ke bucket akun A ke salah satu pengguna di akun B.

Kebijakan S3 bucket di akun A mungkin terlihat seperti kebijakan berikut. Dalam contoh ini, bucket S3 akun A diberi nama amzn-s3-demo-bucket, dan nomor akun B adalah 111122223333. Itu tidak menentukan pengguna individual atau pengguna kelompok di akun B, hanya akun itu sendiri.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

Atau, akun A dapat menggunakan Amazon S3 Access Control Lists (ACLs) untuk memberikan akses akun B ke bucket S3 atau satu objek di dalam bucket. Dalam hal ini, satu-satunya hal yang berubah adalah bagaimana akun A memberikan akses ke akun B. Akun B masih menggunakan kebijakan untuk mendelegasikan akses ke IAM grup di akun B, seperti yang dijelaskan di bagian selanjutnya dari contoh ini. Untuk informasi selengkapnya tentang mengontrol akses pada bucket dan objek S3, buka Kontrol Akses di Panduan Pengguna Layanan Penyimpanan Sederhana Amazon.

Administrator akun B dapat membuat sampel kebijakan berikut. Kebijakan ini memungkinkan akses baca ke kelompok atau pengguna di akun B. Kebijakan sebelumnya memberikan akses ke akun B. Namun demikian, kelompok individu dan pengguna di akun B tidak dapat mengakses sumber daya sampai suatu kelompok atau pengguna memberikan izin secara jelas ke sumber daya tersebut. Izin dalam kebijakan ini hanya dapat menjadi subset dari izin yang ada di kebijakan lintas akun sebelumnya. Akun B tidak dapat memberikan lebih banyak izin untuk kelompok dan penggunanya daripada yang diberikan akun A ke akun B dalam kebijakan pertama. Dalam kebijakan ini, elemen Action secara jelas ditentukan untuk hanya mengizinkan tindakan List, dan elemen Resource kebijakan ini sesuai dengan Resource untuk kebijakan bucket yang diterapkan oleh akun A.

Untuk menerapkan kebijakan ini, akun B gunakan IAM untuk melampirkannya ke pengguna (atau grup) yang sesuai di akun B.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

Menggunakan kebijakan berbasis sumber daya untuk mendelegasikan akses ke antrian Amazon di akun lain SQS

Dalam contoh berikut, akun A memiliki SQS antrian Amazon yang menggunakan kebijakan berbasis sumber daya yang dilampirkan pada antrian untuk memberikan akses antrian ke akun B. Kemudian akun B menggunakan kebijakan IAM grup untuk mendelegasikan akses ke grup di akun B.

Contoh kebijakan antrean berikut memberi akun B izin untuk melakukan tindakan SendMessage dan ReceiveMessage pada antrean akun A yang disebut antrean1, tetapi hanya antara tengah hari hingga pukul 15.00 pada 30 November 2014. Nomor akun Akun B adalah 1111-2222-3333. Akun A menggunakan Amazon SQS untuk menerapkan kebijakan ini.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}

Kebijakan akun B untuk mendelegasikan akses ke suatu kelompok di akun B dapat terlihat seperti contoh berikut. Akun B menggunakan IAM untuk melampirkan kebijakan ini ke grup (atau pengguna).

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}

Dalam contoh kebijakan IAM pengguna sebelumnya, akun B menggunakan wildcard untuk memberikan akses penggunanya ke semua SQS tindakan Amazon pada antrean akun A. Namun, akun B hanya dapat mendelegasikan akses jika akun B telah diberi akses. Kelompok akun B yang memiliki kebijakan kedua dapat mengakses antrean hanya antara tengah hari hingga pukul 15.00 pada 30 November 2014. Pengguna hanya dapat melakukan ReceiveMessage tindakan SendMessage dan, sebagaimana didefinisikan dalam kebijakan SQS antrian Amazon akun A.

Tidak dapat mendelegasikan akun ketika akun ditolak aksesnya

Sesi Akun AWS tidak dapat mendelegasikan akses ke sumber daya akun lain jika akun lain secara eksplisit menolak akses ke akun induk pengguna. Penolakan ini meluas ke para pengguna dalam akun tersebut, baik apakah pengguna sudah memiliki kebijakan yang memberikan akses kepada mereka atau belum.

Sebagai contoh, akun A menyusun kebijakan bucket pada bucket S3 akun A yang secara eksplisit menolak akses akun B ke bucket akun A. Tetapi akun B menulis kebijakan IAM pengguna yang memberi pengguna di akun B akses ke keranjang akun A. Penolakan eksplisit yang diterapkan pada bucket S3 akun A menyebar ke pengguna di akun B. Ini mengesampingkan kebijakan IAM pengguna yang memberikan akses ke pengguna di akun B. (Untuk informasi terperinci bagaimana izin dievaluasi, lihat.) Logika evaluasi kebijakan

Kebijakan bucket Akun A dapat terlihat seperti kebijakan berikut ini. Dalam contoh ini, bucket S3 akun A diberi nama amzn-s3-demo-bucket, dan nomor akun B adalah 1111-2222-3333. Akun A menggunakan Amazon S3 untuk menerapkan kebijakan ini.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
  }
}

Penolakan secara eksplisit ini membatalkan kebijakan apa pun dalam akun B yang memberikan izin untuk mengakses bucket S3 dalam akun A.