Kebijakan AccessControl

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Baca dokumentasi Apigee Edge.

ikon kebijakan

Apa

Kebijakan AccessControl memungkinkan Anda mengizinkan atau menolak akses ke API berdasarkan alamat IP tertentu.

Kebijakan ini adalah Kebijakan standar dan dapat di-deploy ke jenis lingkungan apa pun. Tidak semua pengguna perlu mengetahui tentang kebijakan dan jenis lingkungan. Untuk mengetahui informasi tentang jenis kebijakan dan ketersediaan untuk setiap jenis lingkungan, lihat Jenis kebijakan.

Video: Tonton video singkat untuk mempelajari lebih lanjut tentang cara mengizinkan atau menolak akses ke API Anda melalui alamat IP tertentu.

Meskipun dapat melampirkan kebijakan ini di mana saja dalam alur proxy API, kemungkinan besar Anda perlu memeriksa alamat IP pada awal alur ( Request / ProxyEndpoint / PreFlow), bahkan sebelum autentikasi atau pemeriksaan kuota.

Anda juga harus mempertimbangkan penggunaan Google Cloud Armor dengan Apigee sebagai cara alternatif untuk mengamankan API Anda.

Sampel

Nilai mask dalam sampel IPv4 berikut mengidentifikasi mana dari empat octet (8, 16, 24, 32 bit) yang dipertimbangkan oleh aturan pencocokan saat mengizinkan atau menolak akses. Nilai defaultnya adalah 32. Lihat atribut mask dalam referensi Elemen untuk informasi selengkapnya.

Tolak 198.51.100.1

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="32">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Tolak semua permintaan dari alamat klien: 198.51.100.1

Izinkan permintaan dari alamat klien lainnya.

Menolak menggunakan variabel

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="{kvm.mask.value}">{kvm.ip.value}</SourceAddress>
    </MatchRule>
    </IPRules>
</AccessControl>

Misalnya Anda menggunakan peta nilai kunci (KVM) guna menyimpan nilai untuk penyamaran dan IP. Ini adalah pendekatan praktis untuk mengubah IP dan penyamaran selama runtime tanpa harus mengupdate dan men-deploy ulang proxy API Anda. Anda dapat menggunakan kebijakan KeyValueMapOperations untuk mengambil variabel yang berisi nilai untuk kvm.mask.value dan kvm.ip.value (dengan asumsi itulah nama variabel dalam kebijakan KVM yang berisi nilai mask dan nilai IP dari KVM). Jika nilai yang Anda ambil adalah 24 untuk mask dan 198.51.100.1 untuk alamat IP, kebijakan AccessControl akan menolak semua permintaan dari: 198.51.100.*

Semua alamat klien lainnya akan diizinkan.

Tolak 198.51.100.*

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
    </IPRules>
</AccessControl>

Tolak semua permintaan dari alamat klien: 198.51.100.*

Izinkan permintaan dari alamat klien lainnya.

198,51..

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
       <SourceAddress mask="16">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Tolak semua permintaan dari alamat klien: 198.51.*.*

Izinkan permintaan dari alamat klien lainnya.

Tolak 198.51.100.*, izinkan 192.0.2.1

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="32">192.0.2.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Tolak semua permintaan dari alamat klien: 198.51.100.*, tetapi izinkan 192.0.2.1.

Izinkan permintaan dari alamat klien lainnya.

Izinkan 198.51..

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="16">198.51.100.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Izinkan semua permintaan dari alamat: 198.51.*.*

Menolak permintaan dari alamat klien lain.

Izinkan beberapa IP

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "ALLOW">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
     </MatchRule>
  </IPRules>
</AccessControl>

Izinkan permintaan dari alamat klien: 198.51.100.* 192.0.2.* 203.0.113.*

Tolak semua alamat lainnya.

Menolak beberapa IP

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Menolak permintaan dari alamat klien: 198.51.100.* 192.0.2.* 203.0.113.*

Izinkan semua alamat lain.

Mengizinkan beberapa IP, menolak beberapa IP

<AccessControl name="ACL">
  <IPRules noRuleMatchAction = "DENY">
    <MatchRule action = "DENY">
      <SourceAddress mask="24">198.51.100.1</SourceAddress>
      <SourceAddress mask="24">192.0.2.1</SourceAddress>
      <SourceAddress mask="24">203.0.113.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "ALLOW">
      <SourceAddress mask="16">198.51.100.1</SourceAddress>
      <SourceAddress mask="16">192.0.2.1</SourceAddress>
      <SourceAddress mask="16">203.0.113.1</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

Izinkan: 198.51.*.* 192,0.*.* 203,0.*.*

Menolak subset dari daftar yang diizinkan: 198.51.100.* 192.0.2.* 203.0.113.*

Catatan penggunaan

Selain melindungi API Anda dari IP berbahaya, kebijakan AccessControl juga memberi Anda kontrol atas akses IP yang sah. Misalnya, jika Anda hanya ingin komputer di bawah kendali perusahaan Anda mengakses API yang diekspos di lingkungan pengujian, Anda dapat mengizinkan rentang alamat IP untuk jaringan internal. Developer yang bekerja dari rumah dapat mengakses API ini menggunakan VPN.

Konfigurasi dan eksekusi kebijakan AccessControl melibatkan hal-hal berikut:

Tentukan kumpulan aturan pencocokan dengan salah satu dari dua tindakan (ALLOW atau DENY) yang terkait dengan masing-masing tindakan.
Untuk setiap aturan pencocokan, tentukan alamat IP (elemen SourceAddress).
- Lihat Cara kebijakan memilih alamat IP yang akan dievaluasi untuk menentukan alamat IP dalam pesan yang Anda konfigurasi aturan untuk ditangani.
- Konfigurasikan mask untuk setiap alamat IP. Anda mengizinkan atau menolak akses berdasarkan nilai mask di alamat IP. Lihat Tentang penyamaran IP dengan notasi CIDR.
Tentukan urutan pengujian aturan.
Semua aturan pencocokan dijalankan dalam urutan yang ditentukan. Jika aturan cocok, tindakan terkait akan dieksekusi dan aturan pencocokan yang mengikuti akan dilewati.
- Jika aturan yang sama dikonfigurasi dengan tindakan ALLOW dan DENY, aturan yang ditentukan terlebih dahulu sesuai urutan akan dipicu dan aturan berikutnya (dengan tindakan lainnya) akan dilewati.

Cara kebijakan memilih alamat IP yang akan dievaluasi

Alamat IP dapat berasal dari berbagai sumber dalam permintaan. Misalnya, header X-Forwarded-For mungkin berisi satu atau beberapa alamat IP. Bagian ini menjelaskan cara mengonfigurasi kebijakan AccessControl untuk mengevaluasi alamat IP yang tepat yang Anda inginkan untuk dievaluasi.

Untuk Apigee Hybrid, sebaiknya Anda menyiapkan load balancer di depan cluster Kubernetes. Load balancer mungkin berupa L7 (HTTP aware) atau L4 (TCP aware). Load balancer L7 dapat menambahkan alamat IP sumber klien ke header X-Forwarded-For (XFF). Load balancer L4 harus dikonfigurasi untuk menggunakan protokol PROXY. Baca panduan load balancer Anda tentang cara mengaktifkan dukungan protokol PROXY. Untuk mengaktifkan protokol PROXY di Ingress, lihat Alamat IP sumber klien asli dalam dokumentasi Istio.

Berikut adalah logika yang digunakan kebijakan AccessControl untuk menentukan alamat IP yang akan dievaluasi:

Header X-Forwarded-For

Apigee secara otomatis mengisi header X-Forwarded-For dengan alamat IP yang diterimanya dari handshake TCP eksternal terakhir (seperti IP klien atau router). Jika ada beberapa alamat IP di header, alamat tersebut kemungkinan adalah rantai server yang memproses permintaan. Namun, daftar alamat juga dapat berisi alamat IP yang di-spoofing. Jadi, bagaimana kebijakan tersebut mengetahui alamat mana yang harus dievaluasi?

Dimensi X-Forwarded-For di analisis Apigee

Apigee Analytics menuliskan nilai header X-Forwarded-For ke dimensi x_forwarded_for_ip. Untuk menentukan IP klien yang membuat permintaan ke Apigee, gunakan nilai dalam dimensi ax_resolved_client_ip, tetapi kecualikan ax_true_client_ip, yang tidak didukung dengan kebijakan AccessControl. Lihat Referensi metrik, dimensi, dan filter Analytics.

Tentang penyamaran IP dengan notasi CIDR

Notasi CIDR (Classless Inter-Domain Routing) adalah cara untuk menunjukkan rentang alamat IP melalui masking. Ini berlaku untuk IPv4 dan IPv6. Begini cara kerjanya. Kita akan menggunakan IPv4 dalam contoh kita agar lebih praktis.

Alamat IP adalah kumpulan angka yang dipisahkan oleh titik. Dalam istilah biner, setiap grup adalah jumlah bit tertentu (8 untuk IPv4 dan 16 untuk IPv6). Alamat IPv4 198.51.100.1 terlihat seperti ini dalam biner:

11000110.00110011.01100100.00000001

Itu 4 kelompok yang terdiri dari 8 bit, atau total 32 bit. Dengan CIDR, Anda dapat menunjukkan rentang dengan menambahkan /number (1-32) ke alamat IP, seperti ini:

198.51.100.1/24

Dalam hal ini, 24 adalah angka yang akan Anda gunakan untuk nilai atribut mask dalam kebijakan ini.

Notasi ini berarti, "Pertahankan 24 bit pertama persis sebagaimana adanya, bit yang tersisa dapat berupa nilai 0 sampai 255". Contoh:

Biarkan tetap seperti apa adanya	Nilai yang mungkin untuk grup terakhir
198.51.100	0 - 255

Perhatikan bahwa mask terjadi di akhir grup tiga. Hal ini membuat semuanya tampak bagus dan rapi, pada intinya membuat mask seperti ini: 198.51.100.*. Pada umumnya, menggunakan kelipatan 8 (IPv4) dan 16 (IPv6) akan memberi Anda level penyamaran yang Anda inginkan:

IPv4: 8, 16, 24, 32

IPv6: 16, 32, 48, 64, 80, 96, 112, 128

Namun, Anda dapat menggunakan angka lain untuk kontrol yang lebih mendetail, yang melibatkan sedikit penghitungan biner. Berikut ini contoh penggunaan mask 30, seperti pada 198.51.100.1/30, dengan 1 terakhir adalah 00000001 dalam biner:

Biarkan tetap seperti apa adanya	Nilai yang memungkinkan
11000110.00110011.01100100.000000 (30 bit pertama)	00000000, 00000001, 00000010, atau 00000011
198.51.100.	0, 1, 2, atau 3

Dalam contoh ini, dengan konfigurasi yang ditetapkan ke <SourceAddress mask="30">198.51.100.1</SourceAddress>, IP berikut akan diizinkan (atau ditolak, bergantung pada aturan Anda):

198.51.100,0
198.51.100.1
198.51.100.2
198.51.100,3

Referensi elemen

Referensi elemen menjelaskan elemen dan atribut kebijakan AccessControl.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control 1</DisplayName>
    <IPRules noRuleMatchAction = "ALLOW">
        <MatchRule action = "ALLOW">
            <SourceAddress mask="32">198.51.100.1</SourceAddress>
        </MatchRule>
        <MatchRule action = "DENY">
            <SourceAddress mask="24">198.51.100.1</SourceAddress>
        </MatchRule>
    </IPRules>
    <ValidateBasedOn>X_FORWARDED_FOR_ALL_IP</ValidateBasedOn>
</AccessControl>

Atribut <AccessControl>

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">

Elemen <ClientIPVariable>

Menentukan variabel flow yang berisi alamat IP yang akan diperiksa oleh kebijakan terhadap IPRules. Jika variabel flow tidak berisi alamat IP yang valid (ipv4 atau ipv6), kebijakan akan menampilkan error.

Misalnya variabel flow disetel ke 12.31.34.52. Dalam contoh berikut, akses ditolak. Jika variabel ditetapkan ke 10.11.12.13, akses akan diberikan.


<AccessControl name='ACL'>
   <ClientIPVariable>FLOW_VARIABLE</ClientIPVariable>
   <IPRules noRuleMatchAction = 'DENY'>
     <MatchRule action = 'ALLOW'>
       <SourceAddress mask='32'>10.11.12.13</SourceAddress>
     </MatchRule>
   </IPRules>
</AccessControl>

Default	T/A
Kehadiran	Opsional
Jenis	Variabel flow

Elemen <IgnoreTrueClientIPHeader>

Elemen <IPRules>

Elemen induk berisi aturan yang mengizinkan atau menolak alamat IP. Atribut noRuleMatchAction memungkinkan Anda menentukan cara menangani alamat IP yang tidak tercakup oleh aturan pencocokan.

<IPRules noRuleMatchAction = "ALLOW">

Default	T/A
Kehadiran	Opsional
Jenis	T/A

Atribut

Atribut	Deskripsi	Jenis	Default	Kehadiran
noRuleMatchAction	Tindakan yang akan diambil (mengizinkan atau menolak akses) jika aturan pencocokan yang ditentukan tidak terselesaikan (tidak cocok). Nilai valid: ALLOW atau DENY	String	IZINKAN	Diperlukan

Elemen <IPRules>/<MatchRule>

Tindakan yang harus dilakukan (mengizinkan atau menolak akses) jika alamat IP cocok dengan SourceAddress yang Anda tentukan.

<IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
        <SourceAddress mask="32">198.51.100.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
        <SourceAddress mask="24">198.51.100.1</SourceAddress>
    </MatchRule>
</IPRules>

Default	T/A
Kehadiran	Opsional
Jenis	T/A

Atribut

Atribut	Deskripsi	Jenis	Default	Kehadiran
action	Tindakan yang akan diambil (mengizinkan atau menolak akses) jika aturan pencocokan yang ditentukan tidak terselesaikan (tidak cocok). Nilai valid: ALLOW atau DENY	String	IZINKAN	Diperlukan

Deskripsi

Jenis

Default

Kehadiran

action

Tindakan yang akan diambil (mengizinkan atau menolak akses) jika aturan pencocokan yang ditentukan tidak terselesaikan (tidak cocok).

Nilai valid: ALLOW atau DENY

String

IZINKAN

Diperlukan

Elemen <IPRules>/<MatchRule>/<SourceAddress>

Rentang alamat IP klien.

Nilai valid: Alamat IP yang valid (notasi desimal bertitik). Untuk perilaku karakter pengganti, gunakan atribut mask.

<IPRules noRuleMatchAction = "ALLOW">
    <MatchRule action = "ALLOW">
        <SourceAddress mask="{variable}">198.51.100.1</SourceAddress>
    </MatchRule>
    <MatchRule action = "DENY">
        <SourceAddress mask="24">{variable}</SourceAddress>
    </MatchRule>
</IPRules>

Seperti yang ditunjukkan pada contoh sebelumnya, elemen SourceAddress juga mendukung Template pesan untuk atribut mask atau alamat IP, yang berarti Anda dapat menetapkan nilai menggunakan variabel yang saat ini tersedia di alur proxy API.

Misalnya, Anda dapat menyimpan alamat IP di peta nilai kunci (KVM) dan menggunakan kebijakan KeyValueMapOperations untuk mengambil alamat IP dan menetapkannya ke variabel (seperti kvm.ip.value). Anda kemudian dapat menggunakan variabel tersebut untuk alamat IP:

<SourceAddress mask="24">{kvm.ip.value}</SourceAddress>

Menyetel mask dan/atau alamat IP dengan variabel akan memberi Anda fleksibilitas untuk mengubah nilai saat runtime tanpa harus mengubah dan men-deploy ulang proxy API Anda.

Default	T/A
Kehadiran	Opsional
Jenis	String (hanya satu alamat IP)

Atribut

Atribut Deskripsi Jenis Default Kehadiran

mask

Atribut	Deskripsi	Jenis	Default	Kehadiran
mask	Atribut `mask` adalah cara untuk menunjukkan rentang alamat IP yang akan diizinkan atau ditolak. Mask sama dengan menggunakan notasi CIDR (Classless Inter-Domain Routing). Contoh: `<SourceAddress mask="24">198.51.100.1</SourceAddress>` sama dengan notasi CIDR berikut: 198.51.100.1/24 Nilai valid: IPv4: 1-32 IPv6: 1-128 Nilai nol (0) hanya berlaku untuk IP 0.0.0.0, sehingga tidak praktis. Menetapkan mask dengan variabel Atribut `mask` juga mendukung Template pesan, yang berarti Anda dapat menetapkan nilai dengan variabel yang saat ini tersedia di alur proxy API. Misalnya, Anda dapat menyimpan nilai mask di KVM dan menggunakan kebijakan KeyValueMapOperations untuk mengambil mask dan menetapkannya ke variabel. Untuk menetapkan mask IP dengan variabel, gunakan format berikut, dengan asumsi variabel tersebut bernama `kvm.mask.value`: `mask="{kvm.mask.value}"`	Bilangan bulat	T/A	Diperlukan

Atribut mask adalah cara untuk menunjukkan rentang alamat IP yang akan diizinkan atau ditolak. Mask sama dengan menggunakan notasi CIDR (Classless Inter-Domain Routing). Contoh:

<SourceAddress mask="24">198.51.100.1</SourceAddress>

sama dengan notasi CIDR berikut:

198.51.100.1/24

Nilai valid:

IPv4: 1-32

IPv6: 1-128

Nilai nol (0) hanya berlaku untuk IP 0.0.0.0, sehingga tidak praktis.

Menetapkan mask dengan variabel

Atribut mask juga mendukung Template pesan, yang berarti Anda dapat menetapkan nilai dengan variabel yang saat ini tersedia di alur proxy API. Misalnya, Anda dapat menyimpan nilai mask di KVM dan menggunakan kebijakan KeyValueMapOperations untuk mengambil mask dan menetapkannya ke variabel. Untuk menetapkan mask IP dengan variabel, gunakan format berikut, dengan asumsi variabel tersebut bernama kvm.mask.value:

mask="{kvm.mask.value}"

Bilangan bulat

T/A

Diperlukan

Elemen <ValidateBasedOn>

Jika header HTTP X-Forwarded-For berisi beberapa alamat IP, gunakan elemen ValidateBasedOn ini untuk mengontrol alamat IP yang akan dievaluasi.

Gunakan pendekatan ini untuk mengevaluasi alamat IP hanya jika Anda yakin tentang validitas alamat IP yang ingin dievaluasi. Misalnya, jika memilih mengevaluasi semua alamat IP di header X-Forwarded-For, Anda harus dapat memercayai validitas alamat tersebut, dan/atau menyiapkan aturan DENY atau ALLOW yang komprehensif untuk mengizinkan hanya IP tepercaya yang memanggil proxy API Anda.

Alamat IP paling kiri di header adalah milik klien, dan yang paling kanan adalah server yang meneruskan permintaan ke layanan saat ini. Alamat IP paling kanan atau terakhir adalah alamat yang diterima Apigee dari handshake TCP eksternal terakhir.

Nilai yang dimasukkan dalam elemen ini memungkinkan Anda menentukan apakah akan memeriksa semua alamat IP di header (default), hanya alamat IP pertama, atau hanya alamat IP terakhir.

<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
    <DisplayName>Access Control 1</DisplayName>
    <IPRules noRuleMatchAction = "ALLOW">
        <MatchRule action = "DENY">
            <SourceAddress mask="32">198.51.100.1</SourceAddress>
        </MatchRule>
    </IPRules>
    <ValidateBasedOn>X_FORWARDED_FOR_ALL_IP</ValidateBasedOn>
</AccessControl>

Default X_FORWARDED_FOR_ALL_IP

Kehadiran Opsional

Nilai valid

Default	`X_FORWARDED_FOR_ALL_IP`
Kehadiran	Opsional
Nilai valid	`X_FORWARDED_FOR_ALL_IP` (default) `X_FORWARDED_FOR_FIRST_IP` `X_FORWARDED_FOR_LAST_IP`

X_FORWARDED_FOR_ALL_IP (default)

X_FORWARDED_FOR_FIRST_IP

X_FORWARDED_FOR_LAST_IP

Skema

Setiap jenis kebijakan ditentukan oleh skema XML (.xsd). Sebagai referensi, skema kebijakan tersedia di GitHub.

Referensi error

Bagian ini menjelaskan kode kesalahan dan pesan error yang ditampilkan dan variabel kesalahan yang disetel oleh Apigee saat kebijakan ini memicu error. Informasi ini penting untuk diketahui apakah Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani kesalahan.

Error runtime

Error ini dapat terjadi saat kebijakan dieksekusi.

Kode kesalahan	Status HTTP	Penyebab	Perbaikan
`accesscontrol.IPDeniedAccess`	`403`	Alamat IP klien, atau alamat IP yang diteruskan dalam permintaan API, cocok dengan alamat IP yang ditentukan dalam elemen `<SourceAddress>` dalam elemen `<MatchRule>` Kebijakan Kontrol Akses, dan atribut `action` dari elemen `<MatchRule>` ditetapkan ke `DENY`.
`accesscontrol.InvalidIPAddressInVariable`	`500`	Variabel flow di `<ClientIPVariable>` berisi alamat IP yang tidak valid.

Variabel kesalahan

Variabel ini ditetapkan saat terjadi error runtime. Untuk informasi selengkapnya, lihat Variabel khusus untuk error kebijakan.

Variabel	Dari mana	Contoh
`fault.name="fault_name"`	`fault_name` adalah nama kesalahan, seperti yang tercantum dalam tabel Error runtime di atas. Nama kesalahan adalah bagian terakhir dari kode kesalahan.	`fault.name Matches "IPDeniedAccess"`
`acl.policy_name.failed`	`policy_name` adalah nama kebijakan yang ditentukan pengguna yang menampilkan kesalahan.	`acl.AC-AllowAccess.failed = true`

Contoh respons kesalahan

Catatan: Untuk penanganan fault, praktik terbaiknya adalah menjebak bagian errorcode dari respons fault. Jangan mengandalkan teks di faultstring karena dapat berubah.

{
   "fault":{
     "faultstring":"Access Denied for client ip : 52.211.243.3"
      "detail":{
         "errorcode":"steps.accesscontrol.IPDeniedAccess"
      }
   }
}

Contoh aturan kesalahan

<FaultRule name="IPDeniedAccess">
    <Step>
        <Name>AM-IPDeniedAccess</Name>
        <Condition>(fault.name Matches "IPDeniedAccess") </Condition>
    </Step>
    <Condition>(acl.failed = true) </Condition>
</FaultRule>

Kebijakan AccessControl

Apa

Sampel

Tolak 198.51.100.1

Menolak menggunakan variabel

Tolak 198.51.100.*

198,51.*.*

Tolak 198.51.100.*, izinkan 192.0.2.1

Izinkan 198.51.*.*

Izinkan beberapa IP

Menolak beberapa IP

Mengizinkan beberapa IP, menolak beberapa IP

Catatan penggunaan

Cara kebijakan memilih alamat IP yang akan dievaluasi

Header X-Forwarded-For

Dimensi X-Forwarded-For di analisis Apigee

Tentang penyamaran IP dengan notasi CIDR

Referensi elemen

Atribut <AccessControl>

Elemen <ClientIPVariable>

Elemen <IgnoreTrueClientIPHeader>

Elemen <IPRules>

Atribut

Elemen <IPRules>/<MatchRule>

Atribut

Elemen <IPRules>/<MatchRule>/<SourceAddress>

Atribut

Elemen <ValidateBasedOn>

Skema

Referensi error

Error runtime

Variabel kesalahan

Contoh respons kesalahan

Contoh aturan kesalahan

198,51..

Izinkan 198.51..