View a markdown version of this page

Menulis kebijakan dalam bahasa alami - Batu Dasar Amazon AgentCore
Gambaran umumContohEfek kebijakanSemantik otorisasiElemen kebijakanContoh kebijakanSintaks kondisiMenggabungkan kondisiPerangkap umum

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

Menulis kebijakan dalam bahasa alami

Policy in AgentCore akan secara otomatis memilih wilayah optimal dalam geografi Anda untuk memproses permintaan inferensi yang dibuat melalui layanan pembuat kebijakan. Ini memaksimalkan sumber daya komputasi yang tersedia, ketersediaan model, dan memberikan pengalaman pelanggan terbaik. Data Anda akan tetap disimpan hanya di wilayah tempat permintaan berasal, namun, petunjuk input dan hasil output dapat diproses di luar wilayah tersebut. Semua data akan dikirim terenkripsi di seluruh jaringan aman Amazon.

Policy in AgentCore akan merutekan permintaan inferensi Anda dengan aman ke sumber daya komputasi yang tersedia dalam wilayah geografis tempat permintaan berasal, sebagai berikut:

  • Permintaan inferensi yang berasal dari Uni Eropa akan diproses di dalam Uni Eropa.

  • Permintaan inferensi yang berasal dari Amerika Serikat akan diproses di Amerika Serikat.

  • Permintaan inferensi yang berasal dari APAC akan diproses dalam APAC.

Gambaran umum

Cedar menyediakan kontrol akses yang tepat, tetapi membutuhkan pembelajaran sintaks formal. NL2cedar memungkinkan Anda untuk:

  1. Tulis persyaratan otorisasi dalam bahasa alami

  2. Secara otomatis mengkonversi ke sintaks Cedar

  3. Verifikasi kebijakan yang dihasilkan sesuai dengan kebutuhan Anda

catatan

Pembuatan kebijakan bahasa alami memerlukan AgentCore Gateway dan mesin kebijakan yang digunakan. Layanan menggunakan skema AgentCore Gateway untuk menghasilkan kebijakan Cedar yang valid. Lihat Memulai dengan Kebijakan di AgentCore untuk petunjuk penyiapan.

catatan

Bahasa alami itu fleksibel, tetapi ketepatan sangat penting untuk keamanan. Kebijakan harus jelas dan tidak ambigu.

Contoh

Kebijakan pengembalian dana dari bagian sebelumnya dapat dinyatakan dalam bahasa alami:

Bahasa alami:

Izinkan kepala sekolah dengan nama pengguna “agen pengembalian dana” untuk memproses pengembalian dana ketika jumlah pengembalian dana kurang dari $500.

Konversi ke Cedar: 

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundTool___process_refund",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/refund-gateway"
)
when {
  principal.hasTag("username") &&
  principal.getTag("username") == "refund-agent" &&
  context.input.amount < 500
};

Efek kebijakan

Kebijakan otorisasi memiliki dua kemungkinan efek: izin dan larang.

Kebijakan izin

Kebijakan izin menentukan apa yang dapat dilakukan pengguna:

  • “Izinkan agen pengembalian dana pengguna untuk memproses pengembalian uang”

  • “Izinkan pengguna dengan direktur peran untuk menyetujui keputusan”

  • “Otorisasi pengguna dengan cakupan admin: tulis untuk memperbarui cakupan”

Kebijakan melarang

Kebijakan larangan menentukan apa yang tidak dapat dilakukan pengguna:

  • “Blokir pengguna dari mengakses model sensitivitas tinggi”

  • “Tolak penjamin emisi junior menyetujui keputusan”

  • “Melarang pengguna memproses pengembalian dana saat validasi risiko tertunda”

Semantik otorisasi

Memahami bagaimana Cedar mengevaluasi kebijakan sangat penting untuk menulis aturan otorisasi yang efektif. Cedar mengikuti tiga prinsip dasar:

  • Secara default, semuanya ditolak - Jika tidak ada kebijakan yang secara eksplisit mengizinkan tindakan, tindakan tersebut secara otomatis diblokir

  • Larangan selalu menang - Jika ada kebijakan larangan yang cocok, akses ditolak meskipun kebijakan izin juga cocok

  • Setidaknya satu izin diperlukan - Agar akses diberikan, setidaknya satu kebijakan izin harus sesuai DAN tidak ada kebijakan larangan yang dapat cocok

Mengapa menggunakan kebijakan larangan jika semuanya ditolak secara default?

Kebijakan larangan memastikan bahwa tindakan tertentu tidak dapat diijinkan secara keliru. Bahkan jika seseorang menulis kebijakan izin yang lebih luas, kebijakan larangan diutamakan dan memblokir akses.

Contoh skenario: 

// Broad permit policy - allows all users to view model results
permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ModelAPI___view_results",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model"
);

// Forbid policy - blocks access to high-sensitivity results
forbid(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ModelAPI___view_results",
  resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/model"
)
when {
  context.input.sensitivity == "high"
};

Hasil: Pengguna dapat melihat hasil sensitivitas rendah dan sedang (izin berlaku), tetapi hasil sensitivitas tinggi selalu diblokir (melarang kemenangan).

Gunakan kebijakan larangan untuk:

  • Pembatasan keamanan eksplisit yang tidak boleh diganti

  • Persyaratan kepatuhan

  • Pematian darurat

  • Membuat pengecualian untuk kebijakan izin yang lebih luas

Elemen kebijakan

Kebijakan otorisasi memerlukan tiga elemen utama:

  1. Siapa - Pengguna atau peran mana yang dapat melakukan tindakan

  2. Apa - Operasi atau alat apa yang dapat mereka gunakan

  3. Kapan - Dalam kondisi atau kendala apa

Spesifikasi utama

Prinsip mengidentifikasi pengguna, peran, atau grup mana yang berlaku kebijakan tersebut.

Ekspresi fleksibel:

  • “Izinkan agen pengembalian dana pengguna untuk...”

  • “Izinkan pengguna dengan nama pengguna refund-agent untuk...”

  • “Pengguna dengan peran agen asuransi dapat...”

  • “Siapa pun dengan cakupan pengembalian dana:tulis berwenang untuk...”

  • “Semua pengguna bisa...”

Bersikaplah spesifik tentang identitas:

Tidak lengkap: ❌ “Izinkan pemrosesan pengembalian dana di bawah $500"

Selesai: ✓ “Izinkan agen pengembalian dana memproses pengembalian uang di bawah $500"

Spesifikasi tindakan

“Apa” mengidentifikasi operasi, alat, atau tindakan yang dikendalikan kebijakan.

Kata kerja tindakan fleksibel:

  • “Izinkan pengguna memproses pengembalian uang”

  • “Izin pemrosesan pengembalian uang”

  • “Pengguna dapat membuat aplikasi”

  • “Otorisasi melihat log audit”

Bersikaplah spesifik tentang alat ini:

Vague: ❌ “Izinkan pengguna mengakses model”

Hapus: ✓ “Izinkan tim sains data mengakses model analitik”

Spesifikasi kondisi

“Kapan” menentukan dalam keadaan apa kebijakan berlaku.

Ekspresi kondisional yang fleksibel:

  • “... ketika jumlahnya kurang dari $500"

  • “... jika wilayahnya adalah AS, CA, atau Inggris”

  • “... hanya ketika status persetujuan disetujui oleh manajer”

  • “... asalkan skor risiko telah diserahkan”

Tepat dengan kondisi:

Tidak jelas: ❌ “Izinkan transfer jika jumlahnya masuk akal”

Tepat: ✓ “Izinkan transfer ketika jumlahnya kurang dari $10.000"

Contoh kebijakan

Contoh-contoh berikut menunjukkan bagaimana menyusun kebijakan bahasa alami dengan prinsip, tindakan, dan kondisi yang jelas.

Contoh 1: User-Based Kebijakan Sederhana

Izinkan agen pengembalian dana pengguna untuk memproses pengembalian dana ketika jumlahnya kurang dari $500.

Elemen:

  • Siapa: agen pengem balian dana pengguna

  • Apa: proses pengembalian uang

  • Kapan: jumlahnya kurang dari $500

Contoh 2: Role-Based dengan Beberapa Kondisi

Izinkan pengguna dengan peran agen asuransi untuk memperbarui cakupan saat jenis pertanggungan adalah kewajiban atau tabrakan dan polis aktif.

Elemen:

  • Siapa: pengguna dengan peran agen asuransi

  • Apa: per barui cakupan

  • Kapan: jenis pertanggungan adalah kewajiban atau tabrakan DAN polis aktif

Contoh 3: Ak Scope-Based ses

Izinkan pengguna dengan cakupan travel:book untuk membuat pemesanan penerbangan ketika wilayah tersebut bukan UE dan produk memenuhi syarat.

Elemen:

  • Siapa: pengguna dengan cakupan perjalanan: buku

  • Apa: buat pemesanan penerbangan

  • Kapan: wilayah bukan UE DAN produk memenuhi syarat

Contoh 4: Setiap orang dengan kendala

Izinkan semua pengguna untuk melihat hasil model ketika sensitivitas data rendah atau sedang dan jenis hasilnya adalah skor risiko.

Elemen:

  • Siapa: semua pengguna

  • Apa: lihat hasil model

  • Kapan: sensitivitas data rendah atau sedang DAN jenis hasilnya adalah skor risiko

Sintaks kondisi

Kondisi adalah di mana kebijakan sering menjadi ambigu. Berikut cara menulis kondisi yang jelas dan dapat diuji.

Perbandingan Numerik

Contoh yang bagus:

  • “ketika jumlahnya kurang dari $500"

  • “ketika jumlah pertanggungan di bawah 5 juta”

  • “ketika klaim melebihi $10.000.000"

  • “ketika jumlah penumpang tepat 2"

Hindari istilah yang tidak jelas:

  • ❌ “ketika jumlahnya kecil”

  • ❌ “ketika cakupannya tinggi”

Pencocokan String

Cocokan yang tepat:

  • “Ketika wilayah itu adalah AS”

  • “ketika metode pembayarannya adalah kartu kredit”

  • “Ketika status disetujui”

Beberapa opsi:

  • “ketika wilayah tersebut adalah AS atau CA atau Inggris”

  • “ketika jenis keputusan disetujui atau merujuk”

Pencocokan pola:

  • “ketika email berisi @example .com”

  • “ketika cakupan berisi admin:write”

Negasi:

  • “ketika wilayah itu bukan Uni Eropa”

  • “Ketika klasifikasi tidak dibatasi”

Kondisi Boolean

Pemeriksaan langsung:

  • “ketika produk memenuhi syarat”

  • “ketika skor risiko diserahkan”

  • “ketika pengiriman ekspres diminta”

Negasi:

  • “ketika produk tidak memenuhi syarat”

  • “ketika skor risiko tidak diserahkan”

Keberadaan Lapangan

Bidang yang mewajibkan:

  • “Ketika alasan diberikan”

  • “ketika ID aplikasi ada”

  • “ketika tanggal pengembalian ditentukan”

Menggabungkan kondisi

Kebijakan nyata seringkali membutuhkan beberapa kondisi. Gunakan konektor logis yang jelas.

DAN Logika (Semua Harus Benar)

Gunakan kata-kata seperti: “dan”, “juga”, “tambahan”, “sementara”, “dengan”

Contoh:

Izinkan aplikasi ketika wilayah tersebut adalah AS dan produk memenuhi syarat dan wilayahnya aktif.

ATAU Logika (Setidaknya Satu Harus Benar)

Gunakan kata-kata seperti: “atau”, “alternatif”, “salah satu”

Contoh:

Izinkan persetujuan ketika klaim melebihi $10.000.000 atau tingkat risiko tinggi atau kritis.

Logika Kompleks

Untuk kondisi yang kompleks, gunakan struktur yang jelas:

Contoh:

Izinkan finalisasi saat tahap alur kerja selesai ditinjau atau disetujui, dan status kepatuhan dilewati, dan otoritasnya adalah manajer atau direktur.

Perangkap umum

Hindari kesalahan umum ini saat menulis kebijakan bahasa alami untuk memastikan mereka mengonversi dengan benar ke sintaks Cedar.

Kesalahan 1: Prinsip yang tidak jelas

Buruk: “Izinkan akses ke alat pengembalian dana”

Bagus: “Izinkan agen pengembalian dana pengguna untuk mengakses alat pengembalian dana”

Kesalahan 2: Tindakan Ambigu

Buruk: “Izinkan pengguna mengakses data”

Bagus: “Izinkan pengguna untuk melihat catatan pasien”

Kesalahan 3: Kondisi Subjektif

Buruk: “Izinkan transfer ketika jumlahnya masuk akal”

Bagus: “Izinkan transfer ketika jumlahnya kurang dari $10.000"

Kesalahan 4: Kondisi Hilang

Buruk: “Izinkan pengguna dengan lingkup admin:write untuk memperbarui cakupan”

Bagus: “Izinkan pengguna dengan cakupan admin:write untuk memperbarui cakupan saat polis aktif dan jenis cakupannya adalah kewajiban atau tabrakan”

Kesalahan 5: Logika Tidak Jelas

Buruk: “Izinkan ketika A atau B dan C”

Bagus: “Izinkan kapan (A atau B) dan C” atau “Izinkan ketika A atau (B dan C)”