Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Logika evaluasi
Tujuan pada waktu evaluasi adalah memutuskan apakah permintaan pemberian harus diizinkan atau ditolak. Logika evaluasi mengikuti beberapa aturan dasar:
-
Secara default, semua permintaan untuk menggunakan sumber daya Anda yang berasal dari siapa pun selain Anda ditolak
-
Perizinan mengabaikan penolakan default apa pun
-
Penolakan eksplisit mengabaikan izin apa pun.
-
Urutan evaluasi kebijakan tidak penting
Bagan alir dan diskusi berikut menjelaskan secara lebih rinci bagaimana keputusan dibuat.
| 1 |
Keputusan dimulai dengan penolakan default. |
| 2 |
Kemudian, kode penerapan mengevaluasi semua kebijakan yang diterapkan pada permintaan (berdasarkan sumber daya, penanggung jawab, tindakan, dan syarat). Urutan yang digunakan kode penerapan untuk mengevaluasi kebijakan tidak penting. |
| 3 |
Dalam semua kebijakan tersebut, kode penerapan mencari instruksi penolakan eksplisit yang akan diterapkan pada permintaan. Jika menemukan satu penolakan pun, kode penerapan akan mengembalikan keputusan "menolak" dan proses selesai (ini adalah penolakan eksplisit; untuk informasi lebih lanjut, lihat Penolakan eksplisit). |
| 4 |
Jika penolakan eksplisit tidak ditemukan, kode penerapan mencari instruksi "mengizinkan" apa pun yang akan diterapkan pada permintaan. Jika menemukan satu instruksi pun, kode penerapan mengembalikan keputusan "mengizinkan" dan proses selesai (layanan melanjutkan untuk memproses permintaan). |
| 5 |
Jika tidak ada perizinan ditemukan, maka keputusan akhir adalah "menolak" (karena tidak ada penolakan eksplisit atau memungkinkan, ini dianggap sebagai blokir secara default (untuk informasi selengkapnya, lihat Blokir secara default). |
Interaksi penolakan eksplisit dan blokir secara default
Kebijakan menghasilkan blokir secara default jika tidak diterapkan secara langsung pada permintaan. Misalnya, jika pengguna meminta untuk menggunakan AmazonSNS, tetapi kebijakan tentang topik tersebut Akun AWS sama sekali tidak merujuk ke pengguna, maka kebijakan tersebut akan menghasilkan penolakan default.
Kebijakan juga mengakibatkan blokir secara default jika suatu syarat dalam pernyataan tidak terpenuhi. Jika semua syarat dalam pernyataan terpenuhi, maka kebijakan menghasilkan perizinan atau penolakan eksplisit, berdasarkan nilai elemen Efek dalam kebijakan. Kebijakan tidak menentukan apa yang harus dilakukan jika syarat tidak terpenuhi, sehingga hasil default dalam kasus tersebut adalah blokir secara default.
Misalnya, katakanlah Anda ingin mencegah permintaan masuk dari Antartika. Anda menulis kebijakan (disebut Kebijakan A1) yang mengizinkan permintaan hanya jika tidak datang dari Antartika. Diagram berikut menggambarkan kebijakan.
Jika seseorang mengirimkan permintaan dari AS, syaratnya terpenuhi (permintaannya bukan dari Antartika). Oleh karena itu, permintaan diizinkan. Namun, jika seseorang mengirimkan permintaan dari Antartika, syarat tidak terpenuhi, dan oleh karena itu hasil kebijakan adalah blokir secara default.
Anda dapat mengubah hasilnya menjadi penolakan eksplisit dengan menulis ulang kebijakan (bernama Kebijakan A2) seperti dalam diagram berikut. Di sini, kebijakan secara eksplisit menolak permintaan jika berasal dari Antartika.
Jika seseorang mengirimkan permintaan dari Antartika, syarat terpenuhi, dan karena itu hasil kebijakan adalah penolakan eksplisit.
Perbedaan antara blokir secara default dan penolakan eksplisit penting karena blokir secara default dapat diabaikan oleh perizinan, tetapi penolakan eksplisit tidak da[at diabaikan. Misalnya, ada kebijakan lain yang mengizinkan permintaan jika tiba pada tanggal 1 Juni 2010. Bagaimana kebijakan ini mempengaruhi hasil keseluruhan ketika digabungkan dengan kebijakan yang membatasi akses dari Antartika? Kami akan membandingkan hasil keseluruhan saat menggabungkan kebijakan berbasis tanggal (akan disebut Kebijakan B) dengan kebijakan A1 dan A2 sebelumnya. Skenario 1 menggabungkan Kebijakan A1 dengan Kebijakan B, dan Skenario 2 menggabungkan Kebijakan A2 dengan Kebijakan B. Gambar dan diskusi berikut menunjukkan hasil saat permintaan datang dari Antartika pada 1 Juni 2010.
Dalam Skenario 1, Kebijakan A1 mengembalikan blokir secara default, seperti yang dijelaskan sebelumnya dalam bagian ini. Kebijakan B mengembalikan perizinan karena kebijakan (menurut definisi) mengizinkan permintaan yang datang pada 1 Juni 2010. Perizinan dari Kebijakan B mengabaikan blokir secara default dari Kebijakan A1, dan oleh karena itu permintaan diperbolehkan.
Dalam Skenario 2, Kebijakan A2 mengembalikan penolakan eksplisit, seperti yang dijelaskan sebelumnya dalam bagian ini. Sekali lagi, Kebijakan B mengembalikan perizinan. Perizinan dari Kebijakan A2 mengabaikan perizinan dari Kebijakan B, dan oleh karena itu permintaan ditolak.
