Evaluasi kebijakan dengan Cedar

Halaman ini menjelaskan cara Policy Engine Multi-Party Compute (MPC) mengevaluasi kebijakan transaksi yang ditulis dalam bahasa kebijakan Cedar, menangani skenario lintas-chain, dan menyelesaikan kolom metadata opsional atau yang dihilangkan.

Prinsip Evaluasi Inti

Policy Engine menggunakan Cedar Policy Language untuk mengizinkan operasi penandatanganan kriptografis. Mesin ini mengevaluasi kebijakan secara deterministik menggunakan tiga aksioma dasar:

  1. Default Deny: Semua operasi ditolak secara implisit. Agar diizinkan, operasi harus cocok dengan setidaknya satu kebijakan permit yang aktif. Jika tidak ditemukan kebijakan permit yang cocok, keputusan akhir adalah DENY.
  2. Larangan Eksplisit: Kebijakan forbid bertindak sebagai penggantian mutlak. Jika suatu operasi cocok dengan kebijakan forbid yang aktif, keputusan akan segera ditetapkan ke DENY, terlepas dari kebijakan permit yang cocok yang seharusnya mengizinkan operasi tersebut.
  3. Kolom yang Tidak Ada Berarti "Tidak Ada Kecocokan" (Lewati): Jika aturan mencari kolom yang tidak ada dalam payload transaksi (seperti kolom opsional yang tidak disertakan), Cedar tidak akan error. Aturan tersebut akan diperlakukan sebagai "tidak cocok" (dievaluasi sebagai salah) dan beralih ke aturan berikutnya.

Matriks Evaluasi Logis

Tabel berikut menunjukkan cara Policy Engine mengevaluasi kombinasi aturan.

Untuk semua skenario, asumsikan:

  • Pemanggil transaksi (direpresentasikan sebagai principal dalam kebijakan Cedar) adalah Alice (User::"alice"). Dalam Multi-Party Compute, principal merepresentasikan persona atau identitas yang meminta otorisasi untuk operasi penandatanganan kriptografis (seperti penanda tangan manusia, klien layanan otomatis, atau akun sistem backend).
  • Transaksi ini mentransfer tepat 1 ETH (direpresentasikan sebagai 1.000.000.000 unit nanocoin berskala di context.transaction.spend_amount_scaled).
Skenario Kebijakan Aktif Hasil Alasan
Skenario 1: Status kosong Tidak ada kebijakan aktif. DENY Secara default, semua operasi diblokir kecuali jika diizinkan secara eksplisit oleh kebijakan permit yang cocok.
Skenario 2: Satu kecocokan izin 
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 10000000000
};

Memungkinkan hingga 10 ETH

 PERMIT Parameter transaksi memenuhi kondisi kebijakan. Karena tidak ada kebijakan forbid yang bertentangan, permintaan diizinkan.
Skenario 3: Ketidakcocokan izin tunggal 
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 500000000
};

Mengizinkan hingga 0,5 ETH

 DENY Jumlah transfer (1 ETH) melebihi batas kebijakan. Karena tidak ada aturan permit yang cocok, penolakan default akan memblokir transaksi.
Skenario 4: Beberapa kebijakan izin

Kebijakan A:

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 500000000
};

Mengizinkan hingga 0,5 ETH

Kebijakan B:

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 5000000000
};

Memungkinkan hingga 5 ETH

 PERMIT Meskipun Kebijakan A tidak cocok, Kebijakan B cocok. Anda hanya memerlukan satu kebijakan permit yang cocok untuk mengizinkan transaksi.
Skenario 5: Konflik izin dan larangan

Kebijakan A (izin):

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 5000000000
};

Memungkinkan hingga 5 ETH

Kebijakan B (melarang):

forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.recipient == "0xBlockedAddress"
};

Mengasumsikan tujuan adalah 0xBlockedAddress

 DENY Transfer dikirim ke 0xBlockedAddress. Meskipun Kebijakan A mengizinkan jumlah transaksi, tujuan transaksi cocok dengan kriteria Kebijakan B. Aturan forbid eksplisit menggantikan Kebijakan A dan memblokir transaksi.
Skenario 6: Kebijakan larangan yang tidak cocok

Kebijakan yang sama seperti dalam skenario sebelumnya

 PERMIT Transfer dikirim ke alamat yang aman (misalnya, 0xSafeAddress). Kebijakan A berhasil dicocokkan, dan Kebijakan B tidak cocok karena tujuannya bukan 0xBlockedAddress. Jika tidak ada aturan larangan yang cocok, aturan izin akan diterapkan.

Skenario multi-rantai dan kolom opsional

Meskipun matriks sebelumnya menunjukkan prioritas logis inti dari aturan yang diizinkan dan dilarang, skenario berikut menggambarkan cara Policy Engine mengevaluasi aturan dalam lingkungan multi-chain: khususnya saat mengeksekusi terhadap kolom opsional atau skema jaringan blockchain yang berbeda.

Catatan: Normalisasi Data Bernilai Nol Untuk mencegah error evaluasi yang tidak terduga dan memastikan prediktabilitas kebijakan, lapisan penguraian Policy Engine menormalisasi kolom string dan byte yang tidak diisi dalam konteks evaluasi ke nilai nol khusus jenisnya (seperti string kosong "" atau array byte kosong), bukan menghilangkannya.

Perilaku ini memungkinkan Anda membuat draf kebijakan eksplisit yang menargetkan kolom yang tidak diisi tanpa risiko error evaluasi Cedar. Namun, mengakses kolom yang sama sekali tidak ditentukan dalam skema blockchain (seperti gas_limit khusus EVM pada transaksi Bitcoin, atau outputs khusus Bitcoin pada transaksi EVM) akan menghasilkan error evaluasi Cedar pada kebijakan spesifik tersebut, sehingga menyebabkan evaluasi menjadi false (tidak cocok) dan gagal ditutup dengan aman.

Skenario 7: Evaluasi kebijakan lintas rantai dan atribut skema yang tidak dipetakan

  • Konteks: Pemanggil mengirimkan transaksi Bitcoin. Namun, kumpulan kebijakan aktif berisi kebijakan khusus Ethereum:

    permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.schema == "ethereum.transaction.v2" &&
  context.transaction.gas_limit < 100000
};

  • Hasil: DENY

  • Alasan: Atribut intent universal (seperti spend_amount_scaled, recipient, dan max_fee_atomic) dievaluasi secara konsisten di seluruh transaksi Ethereum dan Bitcoin. Jika kebijakan merujuk ke atribut khusus rantai yang tidak ada dalam skema transaksi yang dikirimkan (seperti gas_limit pada transaksi Bitcoin), Cedar akan memperlakukan atribut yang tidak cocok sebagai kegagalan evaluasi, sehingga kebijakan spesifik tersebut akan ditetapkan ke false (tidak cocok) tanpa menghentikan mesin. Karena tidak ada kebijakan permit aktif lain yang cocok dengan transaksi Bitcoin, operasi akan ditolak secara default.

Skenario 8: Bidang Options tidak ada dalam kebijakan permit

  • Konteks: Pemanggil mengirimkan transfer ETH standar (yang tidak menggunakan smart contract). Set kebijakan aktif berisi aturan yang memeriksa interaksi kontrak:

    permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == "0x1111111111111111111111111111111111111111"
};

  • Hasil: DENY

  • Alasan: Untuk transfer ETH standar, asset_contract_address opsional tidak diisi. Parser menormalisasi ini menjadi string kosong bernilai nol "" dalam konteks evaluasi. Mengevaluasi perbandingan "" == "0x1111..." akan menampilkan false (tidak cocok), bukan memunculkan error. Karena tidak ada kebijakan lain yang mengizinkan transfer, operasi akan ditolak secara default.

Skenario 9: Bidang Options tidak ada dalam kebijakan forbid

  • Konteks: Pemanggil mengirimkan transfer ETH standar sebesar 10 ETH. Kumpulan kebijakan terdiri dari:

    • Kebijakan A (izin):

      permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled <= 100000000000
};

    • Kebijakan B (melarang):

      forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == "0xBannedContract"
};

  • Hasil: PERMIT

  • Alasan: Kebijakan A berhasil dicocokkan karena 10 ETH berada di bawah batas. Kebijakan B memeriksa apakah alamat kontrak cocok dengan alamat yang dilarang. Karena normalisasi nilai nol, alamat kontrak yang tidak diisi akan di-resolve ke "". Mengevaluasi perbandingan "" == "0xBannedContract" akan menampilkan false. Karena kebijakan larangan tidak cocok dan kebijakan izin cocok, transaksi diizinkan.

Skenario 10: Pemeriksaan eksplisit kolom kosong atau tidak ada

  • Konteks: Pemanggil mengirimkan transfer ETH standar (yang tidak dikirim ke smart contract). Kumpulan kebijakan terdiri dari:

    • Kebijakan A (izin):

      permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled <= 1000000000000
};

    • Kebijakan B (melarang):

      forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == ""
};

  • Hasil: DENY

  • Alasan: Karena normalisasi parser, asset_contract_address yang tidak ada ditampilkan dalam konteks evaluasi sebagai string kosong "". Mengevaluasi Kebijakan B akan me-resolve kondisi ke true ("" == ""). Kebijakan forbid cocok, dan transaksi ditolak.

Validasi Pra-Evaluasi (Fail-Fast Gate)

Policy Engine menerapkan validasi data yang ketat. Sebelum payload diteruskan ke Cedar untuk evaluasi kebijakan, parser yang mendasarinya akan memvalidasi struktur transaksi, encoding RLP, dan integritas kriptografis.

Skenario 11: Payload transaksi yang salah format dan tidak valid

  • Konteks: Klien mengirimkan urutan byte yang salah format, payload dengan struktur yang tidak valid, atau transaksi yang tidak memiliki kolom kriptografis wajib (misalnya, transaksi EVM dengan struktur RLP yang tidak valid atau parameter gas yang tidak ada).
  • Hasil: gRPC InvalidArgument
  • Alasan: Parser transaksi internal mendeteksi input yang tidak valid di lapisan gateway API. Operasi akan langsung gagal, menampilkan error gRPC InvalidArgument kepada klien, dan evaluasi oleh Cedar Policy Engine akan sepenuhnya diabaikan.