View a markdown version of this page

Menggunakan alias menyimpan kebijakan Izin Terverifikasi Amazon dalam operasi API - Izin Terverifikasi Amazon
Menggunakan alias penyimpanan kebijakan di OperasiMenggunakan alias penyimpanan kebijakan di seluruh Wilayah AWSAlias penyimpanan kebijakan bukanlah mekanisme kontrol lalu lintasMelakukan perubahan penyimpanan kebijakan tanpa downtime

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menggunakan alias menyimpan kebijakan Izin Terverifikasi Amazon dalam operasi API

Setiap operasi Izin Terverifikasi Amazon yang menerima policyStoreId parameter IsAuthorized, seperti IsAuthorizedWithToken, GetPolicyStore, dan, dapat menerima nama alias penyimpanan kebijakan sebagai pengganti ID penyimpanan kebijakan.

penting

Bila Anda menggunakan alias penyimpanan kebijakan sebagai nilai policyStoreId parameter, Anda harus menyertakan policy-store-alias/ awalan. Misalnya, gunakanpolicy-store-alias/example-policy-store, tidakexample-policy-store.

Menggunakan alias penyimpanan kebijakan di Operasi

Per IsAuthorized intah berikut menggunakan alias penyimpanan kebijakan dengan nama example-policy-store untuk mengidentifikasi penyimpanan kebijakan.

AWS CLI
$ aws verifiedpermissions is-authorized \
    --policy-store-id policy-store-alias/example-policy-store \
    --principal entityType=User,entityId=alice \
    --action actionType=Action,actionId=view \
    --resource entityType=Photo,entityId=photo123
catatan

Anda tidak dapat menggunakan alias penyimpanan kebijakan sebagai pengganti policyStoreId bidang untuk DeletePolicyStore operasi.

Menggunakan alias penyimpanan kebijakan di seluruh Wilayah AWS

Salah satu penggunaan alias yang paling kuat adalah pada aplikasi yang berjalan dalam beberapa Wilayah AWS. Misalnya, Anda mungkin memiliki aplikasi global yang menggunakan penyimpanan kebijakan berbeda di setiap Wilayah.

  • Di us-east-1, Anda ingin menggunakan. PSEXAMPLEabcdefg111111

  • Di eu-west-1, Anda ingin menggunakan. PSEXAMPLEabcdefg222222

Anda dapat membuat versi aplikasi yang berbeda di setiap Wilayah atau menggunakan kamus atau pernyataan switch untuk memilih penyimpanan kebijakan yang tepat untuk setiap Wilayah. Tetapi jauh lebih mudah untuk membuat alias penyimpanan kebijakan dengan nama alias penyimpanan kebijakan yang sama di setiap Wilayah. Ingatlah bahwa nama alias penyimpanan kebijakan peka huruf besar-kecil.

AWS CLI
$ aws --region us-east-1 verifiedpermissions create-policy-store-alias \
    --alias-name policy-store-alias/my-app \
    --policy-store-id PSEXAMPLEabcdefg111111

$ aws --region eu-west-1 verifiedpermissions create-policy-store-alias \
    --alias-name policy-store-alias/my-app \
    --policy-store-id PSEXAMPLEabcdefg222222

Kemudian, gunakan alias penyimpanan kebijakan dalam kode Anda. Saat kode berjalan di setiap Wilayah, alias penyimpanan kebijakan akan merujuk ke penyimpanan kebijakan terkait di Wilayah tersebut.

AWS CLI
$ aws verifiedpermissions is-authorized \
    --policy-store-id policy-store-alias/my-app \
    --principal entityType=User,entityId=alice \
    --action actionType=Action,actionId=view \
    --resource entityType=Photo,entityId=photo123

Namun, ada risiko bahwa alias penyimpanan kebijakan mungkin dihapus. Dalam hal ini, upaya aplikasi untuk menggunakan nama alias penyimpanan kebijakan akan gagal, dan Anda mungkin perlu membuat ulang atau memperbarui alias penyimpanan kebijakan. Untuk mengurangi risiko ini, berhati-hatilah dalam memberikan izin kepada kepala sekolah untuk mengelola alias penyimpanan kebijakan yang Anda gunakan di aplikasi Anda.

Alias penyimpanan kebijakan bukanlah mekanisme kontrol lalu lintas

Alias penyimpanan kebijakan adalah nama yang stabil dan ramah untuk penyimpanan kebijakan. Ini bukan mekanisme untuk menggeser, memisahkan, atau membobot lalu lintas otorisasi antara toko kebijakan. Jika Anda terbiasa dengan fitur yang merutekan lalu lintas antar versi sumber daya, seperti alias Lambda, perhatikan bahwa alias penyimpanan kebijakan tidak berperilaku dengan cara yang sama. Secara desain, alias penyimpanan kebijakan lebih dekat dengan alias AWS KMS kunci: alias menyediakan nama yang tahan lama untuk sumber daya, bukan lapisan routing di depannya.

Untuk alasan ini, kami sengaja tidak menyediakan UpdatePolicyStoreAlias operasi. Untuk mengubah penyimpanan kebijakan yang ditunjuk alias penyimpanan kebijakan, Anda menghapus alias penyimpanan kebijakan dan membuat alias penyimpanan kebijakan baru yang memiliki nama yang sama dan menargetkan penyimpanan kebijakan yang berbeda. Ini bukan operasi atom, dan itu tidak memberikan jaminan bahwa mekanisme kontrol lalu lintas akan melakukannya.

Saat Anda mengubah penyimpanan kebijakan yang dipecahkan oleh alias penyimpanan kebijakan, perubahan tersebut tidak berlaku di mana-mana pada saat yang sama:

  • Pemetaan yang diperbarui harus menyebar dari bidang kontrol ke bidang data yang mengevaluasi permintaan otorisasi. Pemetaan tidak menyebar secara instan.

  • Karena resolusi alias penyimpanan kebijakan pada akhirnya konsisten dan dapat di-cache, jendela transisi akan muncul setelah perubahan. Selama jendela ini, penyimpanan kebijakan terkait sebelumnya melayani beberapa permintaan, dan penyimpanan kebijakan yang baru terkait melayani permintaan lainnya. Panjang jendela ini tidak pasti.

Selama jendela ini, aplikasi Anda dapat menerima keputusan otorisasi dari salah satu penyimpanan kebijakan. Karena penyimpanan kebijakan yang berbeda dapat berisi kebijakan, entitas, dan skema yang berbeda, permintaan yang sama dapat menghasilkan keputusan yang berbeda tergantung pada penyimpanan kebijakan mana yang melayaninya. Oleh karena itu, alias penyimpanan kebijakan tidak dapat memberikan pemotongan atom antara penyimpanan kebijakan, dan mereka bukan pengganti strategi penyebaran atau manajemen lalu lintas.

Jangan gunakan alias sebagai mekanisme cut-over

Jangan membangun infrastruktur sebagai kode atau primitif penerapan tingkat tinggi yang mengarahkan ulang alias penyimpanan kebijakan untuk mengalihkan lalu lintas otorisasi dari satu penyimpanan kebijakan ke penyimpanan kebijakan lainnya. Karena perubahan tidak bersifat atomik, permintaan dapat diotorisasi terhadap kedua penyimpanan kebijakan secara bersamaan untuk jangka waktu yang tidak ditentukan. Hal ini dapat menyebabkan keputusan otorisasi yang tidak konsisten. Untuk mengganti toko kebijakan dengan aman, lihatMelakukan perubahan penyimpanan kebijakan tanpa downtime.

Melakukan perubahan penyimpanan kebijakan tanpa downtime

Karena alias penyimpanan kebijakan tidak menyediakan cut-over atom (lihatAlias penyimpanan kebijakan bukanlah mekanisme kontrol lalu lintas), sebaiknya hindari migrasi dari satu penyimpanan kebijakan ke penyimpanan kebijakan lainnya dengan mengarahkan ulang alias penyimpanan kebijakan. Sebagai gantinya, kendalikan migrasi dari dalam aplikasi Anda sehingga Anda dapat memvalidasi penyimpanan kebijakan baru dan memutar kembali secara instan jika perlu. Pendekatan berikut memungkinkan Anda beralih penyimpanan kebijakan tanpa downtime:

  1. Buat penyimpanan kebijakan baru dan berikan alias penyimpanan kebijakan sendiri, sehingga penyimpanan kebijakan saat ini dan penyimpanan kebijakan baru masing-masing memiliki nama yang berbeda dan stabil. Misalnya, terus ar policy-store-alias/example-policy-store ahkan ke penyimpanan kebijakan Anda saat ini dan buat policy-store-alias/example-policy-store-2 untuk penyimpanan kebijakan baru. Jangan menggunakan kembali atau mengarahkan ulang alias penyimpanan kebijakan tunggal untuk melakukan peralihan.

  2. Mereplikasi kebijakan, skema, dan konfigurasi lainnya ke penyimpanan kebijakan baru, dan jalankan secara paralel dengan penyimpanan kebijakan saat ini.

  3. Tambahkan nilai konfigurasi atau tanda fitur ke aplikasi Anda (misalnya, dengan menggunakan AppConfig) yang menentukan alias penyimpanan kebijakan yang berwenang untuk keputusan otorisasi. Jangan mengandalkan perubahan alias itu sendiri untuk mengalihkan lalu lintas.

  4. Jalankan penyimpanan kebijakan baru dalam mode bayangan. Kirim IsAuthorizedWithToken permintaan yang sama IsAuthorized atau ke kedua toko kebijakan dan bandingkan keputusannya. Catat dan selidiki setiap perbedaan hingga penyimpanan kebijakan baru mengembalikan keputusan yang Anda harapkan.

  5. Gunakan tanda fitur untuk mengalihkan keputusan otorisasi ke alias penyimpanan kebijakan baru secara bertahap, misalnya, dalam peluncuran bertahap di host aplikasi atau segmen pengguna Anda. Pantau keputusan otorisasi dan tingkat kesalahan saat Anda melanjutkan.

  6. Gunakan tanda fitur untuk beralih kembali ke alias penyimpanan kebijakan asli segera jika Anda mendeteksi masalah. Karena aplikasi Anda mengontrol sakelar, rollback bersifat instan dan tidak bergantung pada propagasi alias.

  7. Nonaktifkan penyimpanan kebijakan lama dan alias penyimpanan kebijakannya setelah penyimpanan kebijakan baru sepenuhnya divalidasi dan melayani semua lalu lintas.

Pola ini memberi aplikasi Anda, alih-alih propagasi alias, kontrol atas penyimpanan kebijakan mana yang melayani setiap permintaan. Kontrol itulah yang membuat migrasi aman dan dapat dibalik, dan menghindari jendela transisi yang akan diperkenalkan dengan penunjuk ulang alias penyimpanan kebijakan.