Anda sedang melihat dokumentasi Apigee Edge.
Buka
Dokumentasi Apigee X. info
Apa
Kebijakan Kontrol Akses memungkinkan Anda mengizinkan atau menolak akses ke API Anda berdasarkan IP tertentu untuk alamat internal dan eksternal.
Video: Tonton video singkat untuk mempelajari lebih lanjut cara mengizinkan atau menolak yang dapat mengakses API Anda berdasarkan alamat IP tertentu.
Meskipun Anda dapat melampirkan kebijakan ini di mana saja dalam alur proxy API, Anda mungkin ingin memeriksa alamat IP di awal alur ( Permintaan / ProxyEndpoint / PreFlow), bahkan otentikasi atau pemeriksaan kuota.
Contoh
Nilai-nilai mask dalam sampel IPv4 berikut mengidentifikasi mana dari empat oktet (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 mengetahui informasi selengkapnya
tidak akurat atau tidak sesuai.
Menolak 198.51.100.1
<AccessControl name="ACL"> <IPRules noRuleMatchAction = "ALLOW"> <MatchRule action = "DENY"> <SourceAddress mask="32">198.51.100.1</SourceAddress> </MatchRule> </IPRules> </AccessControl>
Menolak semua permintaan dari alamat klien: 198.51.100.1
Izinkan permintaan dari alamat klien lain.
Menolak menggunakan variabel
<AccessControl name="ACL"> <IPRules noRuleMatchAction = "ALLOW"> <MatchRule action = "DENY"> <SourceAddress mask="{kvm.mask.value}">{kvm.ip.value}</SourceAddress> </MatchRule> </IPRules> </AccessControl>
Misalkan Anda menggunakan peta nilai kunci (KVM) untuk menyimpan nilai penyamaran dan IP.
Ini adalah pendekatan praktis untuk mengubah IP dan penyamaran selama {i>runtime<i} tanpa harus memperbarui
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 itu adalah nama variabel yang Anda berikan di kebijakan KVM Anda
yang berisi nilai mask dan nilai IP dari KVM Anda).
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 lain 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>
Menolak semua permintaan dari alamat klien: 198.51.100.*
Izinkan permintaan dari alamat klien lain.
198.51.*.*
<AccessControl name="ACL"> <IPRules noRuleMatchAction = "ALLOW"> <MatchRule action = "DENY"> <SourceAddress mask="16">198.51.100.1</SourceAddress> </MatchRule> </IPRules> </AccessControl>
Menolak semua permintaan dari alamat klien: 198.51.*.*
Izinkan permintaan dari alamat klien lain.
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>
Menolak semua permintaan dari alamat klien: 198.51.100.*, tetapi mengizinkan 192.0.2.1.
Izinkan permintaan dari alamat klien lain.
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 lainnya.
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.*
Menolak 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.
Izinkan beberapa IP, tolak 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 daftar yang diizinkan: 198.51.100.* 192.0.2.* 203.0.113.*
Catatan penggunaan
Selain melindungi API Anda dari IP berbahaya, kebijakan Kontrol Akses juga memberi Anda kendali atas akses IP yang sah. Misalnya, jika Anda ingin komputer yang berada di perusahaan Anda untuk mengakses API yang diekspos di lingkungan pengujian, Anda dapat mengizinkan rentang alamat IP untuk jaringan internal Anda. Pengembang yang bekerja dari rumah dapat mengakses API ini menggunakan VPN.
Konfigurasi dan eksekusi kebijakan Kontrol Akses melibatkan hal-hal berikut:
- Tentukan kumpulan aturan kecocokan dengan salah satu dari dua tindakan (IZINKAN atau Tolak) yang terkait untuk setiap opsi.
- 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 akan ditangani aturannya.
- Konfigurasikan mask untuk setiap alamat IP. Anda mengizinkan atau menolak akses berdasarkan nilai mask di alamat IP-nya. Lihat artikel Tentang penyamaran IP dengan notasi CIDR.
- Tentukan urutan pengujian aturan.
- Semua aturan pencocokan dijalankan dalam urutan tertentu. Ketika aturan cocok,
tindakan yang sesuai akan dieksekusi dan aturan pencocokan berikut dilewati.
- Jika aturan yang sama dikonfigurasi dengan tindakan ALLOW dan DENY, yaitu aturan yang ditentukan pertama dalam urutan dipicu dan aturan berikutnya (dengan tindakan lainnya) dilewati.
Cara kebijakan memilih alamat IP yang akan dievaluasi
Alamat IP dapat berasal dari berbagai sumber dalam permintaan. Misalnya,
Header pesan True-Client-IP
mungkin berisi alamat IP, dan
Header X-Forwarded-For
dapat berisi satu atau beberapa alamat IP. Bagian ini
menjelaskan cara mengkonfigurasi kebijakan AccessControl
untuk mengevaluasi alamat IP yang tepat yang Anda
ingin dievaluasi.
Berikut ini adalah logika yang digunakan kebijakan AccessControl untuk memutuskan alamat IP mana yang mengevaluasi:
1. Header True-Client-IP
Kebijakan ini terlebih dahulu akan memeriksa alamat IP di header True-Client-IP
. Jika
{i>header<i} berisi alamat IP yang valid, kebijakan akan mengevaluasi alamat tersebut.
2. Header X-Forwarded-For
Jika tidak ada header True-Client-IP
, atau jika Anda telah menyetel
Elemen <IgnoreTrueClientIPHeader> ke
true, kebijakan akan mengevaluasi alamat IP di header X-Forwarded-For
.
Edge secara otomatis mengisi header X-Forwarded-For
dengan alamat IP yang diterima dari handshake
TCP eksternal terakhir (seperti IP klien atau
{i>router<i}). Jika ada beberapa alamat IP di {i>header<i}, alamat tersebut akan
kemungkinan adalah rantai server
yang memproses permintaan. Namun, daftar alamat
juga dapat berisi alamat IP palsu. Jadi bagaimana kebijakan itu
mengetahui alamat mana yang
melakukan evaluasi?
Konfigurasi organisasi dan konfigurasi
kebijakan Anda menentukan
X-Forwarded-For
alamat yang dievaluasi oleh kebijakan.
Pertama, periksa untuk melihat apakah properti feature.enableMultipleXForwardCheckForACL
yang ditetapkan di organisasi Anda. Anda dapat menggunakan
Mendapatkan API organisasi untuk diperiksa. Lalu:
- Jika Anda tidak melihat
feature.enableMultipleXForwardCheckForACL
di daftar properti organisasi, artinya properti ditetapkan ke false (default). Dengan menyetel properti ini ke salah (false), kebijakan akan mengevaluasi last di header (terlihat di kolom Alat trace), yang merupakan alamat IP Edge yang diterima dari handshake TCP eksternal terakhir. - Jika
feature.enableMultipleXForwardCheckForACL
di organisasi Anda disetel ke benar (true), konfigurasikan <ValidateBasedOn> untuk menentukan alamat IP yang dievaluasi oleh kebijakan.
Mengubah properti feature.enableMultipleXForwardCheckForACL
Administrator Organisasi Edge dapat menggunakan
Mengupdate API properti organisasi untuk menetapkan
feature.enableMultipleXForwardCheckForACL
.
Contoh API berikut menetapkan properti di Edge untuk Private Cloud. Jika ada properti lain yang ditetapkan di organisasi Anda, pastikan untuk menyertakannya juga. Jika tidak, log tersebut akan dihapus.
curl -u email:password -X POST -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \ "<Organization type="trial" name="MyOrganization"> <DisplayName>MyOrganization</DisplayName> <Properties> <Property name="feature.enableMultipleXForwardCheckForACL">true</Property> <!-- Include other existing properties as well. --> </Properties> </Organization>"
Di Edge untuk Private Cloud, setelah mengubah nilai
feature.enableMultipleXForwardCheckForACL
properti,
Anda harus memulai ulang pemroses pesan, seperti dijelaskan dalam
Memulai/menghentikan/memulai ulang setiap komponen.
X-Forwarded-For dimensi di analisis Apigee
Edge Analytics menulis nilai header X-Forwarded-For
ke
x_forwarded_for_ip
dimensi. Untuk menentukan IP klien yang dibuat
permintaan ke Edge, gunakan nilai dalam ax_true_client_ip
atau
ax_resolved_client_ip
dimensi. Lihat
Metrik, dimensi,
dan referensi filter untuk mengetahui informasi selengkapnya.
Tentang penyamaran IP dengan notasi CIDR
Notasi CIDR (Classless Inter-Domain Routing) adalah cara untuk menunjukkan rentang alamat IP dengan penyamaran. Ini berlaku untuk IPv4 dan IPv6. Begini cara kerjanya. Kita akan menggunakan IPv4 di untuk menyederhanakannya.
Alamat IP adalah kelompok angka yang dipisahkan oleh titik. Dalam istilah biner, setiap grup adalah jumlah bit spesifik (8 untuk IPv4 dan 16 untuk IPv6). Alamat IPv4 198.51.100.1 terlihat seperti ini dalam biner:
11000110.00110011.01100100.00000001
Yaitu 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 atribut mask
dalam kebijakan ini.
Notasi ini berarti, “Jaga 24 bit pertama tetap sama persis, bit yang tersisa dapat mulai dari 0 sampai 255." Contoh:
Pertahankan ini persis seperti apa adanya | Nilai yang mungkin untuk grup terakhir |
---|---|
198.51.100. | 0—255 |
Perhatikan bahwa {i>mask<i} terjadi di akhir kelompok tiga. Hal ini membuat semuanya terlihat bagus dan rapi, {i>essence<i} menciptakan {i>mask<i} seperti ini: 198.51.100.*. Dalam kebanyakan kasus, menggunakan kelipatan 8 (IPv4) dan 16 (IPv6) akan memberi Anda tingkat penyamaran yang Anda inginkan:
IPv4: 8, 16, 24, 32
IPv6: 16, 32, 48, 64, 80, 96, 112, 128
Tetapi, Anda dapat menggunakan angka lain untuk kontrol yang lebih terperinci, yang melibatkan kalkulasi. Berikut ini contoh yang menggunakan mask 30, seperti pada 198.51.100.1/30, dengan 1 adalah 00000001 dalam biner:
Pertahankan ini persis seperti apa adanya | Nilai yang mungkin |
---|---|
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 Kontrol Akses.
<?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>
<AccessControl> atribut
<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1">
Tabel berikut menjelaskan atribut yang umum untuk semua elemen induk kebijakan:
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
name |
Nama internal kebijakan. Nilai atribut Secara opsional, gunakan elemen |
T/A | Wajib |
continueOnError |
Tetapkan ke Setel ke |
salah | Opsional |
enabled |
Setel ke Setel ke |
true | Opsional |
async |
Atribut ini tidak digunakan lagi. |
salah | Tidak digunakan lagi |
<DisplayName> elemen
Gunakan selain atribut name
untuk memberi label kebijakan di
editor proxy UI dengan nama natural language yang berbeda.
<DisplayName>Policy Display Name</DisplayName>
Default |
T/A Jika Anda menghapus elemen ini, nilai atribut |
---|---|
Ketersediaan | Opsional |
Jenis | String |
<IgnoreTrueClientIPHeader> elemen
Jika Anda menyetelnya ke true (benar), kebijakan akan mengabaikan header True-Client-IP
dan mengevaluasi alamat IP di header X-Forwarded-For
, dengan mengikuti
Perilaku evaluasi X-Forwarded-For yang telah Anda konfigurasi.
<AccessControl async="false" continueOnError="false" enabled="true" name="Access-Control-1"> <DisplayName>Access Control-1</DisplayName> <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader> ... </AccessControl>
Default | salah |
---|---|
Ketersediaan | Opsional |
Jenis | Boolean |
<IPRules> elemen
Elemen induk berisi aturan yang mengizinkan atau menolak alamat IP. Tujuan
Atribut noRuleMatchAction
memungkinkan Anda menentukan cara menangani alamat IP yang
tidak tercakup dalam aturan pencocokan Anda.
<IPRules noRuleMatchAction = "ALLOW">
Default | T/A |
---|---|
Ketersediaan | Opsional |
Jenis | T/A |
Atribut
Atribut | Deskripsi | Jenis | Default | Ketersediaan |
---|---|---|---|---|
noRuleMatchAction |
Tindakan yang harus dilakukan (mengizinkan atau menolak akses) jika aturan kecocokan yang ditentukan tidak diselesaikan
(tidak cocok).
Nilai valid: ALLOW atau DENY
|
String | IZINKAN | Wajib |
<IPRules>/<MatchRule> elemen
Tindakan yang akan dilakukan (mengizinkan atau menolak akses) jika alamat IP cocok dengan SourceAddress mendefinisikan.
<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 |
---|---|
Ketersediaan | Opsional |
Jenis | T/A |
Atribut
Atribut | Deskripsi | Jenis | Default | Ketersediaan |
---|---|---|---|---|
action |
Tindakan yang harus dilakukan (mengizinkan atau menolak akses) jika aturan kecocokan yang ditentukan tidak diselesaikan (tidak cocok). Nilai valid: ALLOW atau DENY |
String | IZINKAN | Wajib |
<IPRules>/<MatchRule>/<SourceAddress> elemen
Rentang alamat IP klien.
Nilai valid: Alamat IP yang valid (notasi desimal putus-putus). 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 ditunjukkan dalam contoh sebelumnya, elemen SourceAddress
juga mendukung
Template pesan untuk
atribut mask
atau alamat IP, yang
berarti Anda dapat mengatur nilai menggunakan variabel yang saat ini tersedia di
Alur proxy API.
Misalnya, Anda dapat menyimpan alamat IP di {i>key value map <i}(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 memberi Anda fleksibilitas untuk mengubah nilai runtime tanpa harus mengubah dan men-deploy ulang proxy API Anda.
Default | T/A |
---|---|
Ketersediaan | Opsional |
Jenis | String (hanya satu alamat IP) |
Atribut
Atribut | Deskripsi | Jenis | Default | Ketersediaan |
---|---|---|---|---|
masker |
Atribut
setara 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
|
Bilangan Bulat | T/A | Wajib |
<ValidateBasedOn> elemen
Saat header HTTP X-Forwarded-For
berisi beberapa IP
alamat IP, gunakan elemen ValidateBasedOn
ini untuk mengontrol alamat IP mana
dievaluasi.
Gunakan pendekatan ini untuk mengevaluasi alamat IP hanya jika Anda yakin tentang validitasnya
alamat IP yang ingin dievaluasi. Misalnya, jika Anda memilih
untuk mengevaluasi semua
Alamat IP di header X-Forwarded-For
, Anda harus dapat memercayai
memeriksa validitas alamat tersebut, dan/atau membuat aturan TOLAK atau IZINKAN yang komprehensif agar hanya
IP memanggil proxy API Anda.
Alamat IP paling kiri di {i>header<i} adalah milik klien, dan paling kanan adalah server yang meneruskan permintaan ke layanan saat ini. Alamat IP paling kanan atau terakhir, adalah alamat yang diterima Edge dari handshake TCP eksternal terakhir.
Nilai yang Anda masukkan dalam elemen ini memungkinkan Anda menentukan apakah akan memeriksa semua alamat IP di {i>header<i} (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 |
---|---|
Ketersediaan | Opsional |
Nilai valid |
|
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 kesalahan yang dikembalikan dan variabel kesalahan yang disetel oleh Edge saat kebijakan ini memicu kesalahan. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Penanganan kesalahan.
Error runtime
Error ini dapat terjadi saat kebijakan dijalankan.
Kode error | Status HTTP | Penyebab | Perbaiki |
---|---|---|---|
accesscontrol.IPDeniedAccess |
403 | Alamat IP klien, atau alamat IP yang diteruskan
dalam permintaan API, cocok dengan alamat IP yang ditetapkan dalam elemen <SourceAddress> di dalam
elemen <MatchRule> dari Kebijakan Kontrol Akses, dan atribut action elemen
Elemen <MatchRule> disetel ke DENY . |
build |
Variabel kesalahan
Variabel ini ditetapkan saat terjadi error runtime. Untuk mengetahui informasi selengkapnya, lihat Variabel khusus untuk error kebijakan.
Variabel | Di 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
{ "fault":{ "faultstring":"Access Denied for client ip : 52.211.243.3" "detail":{ "errorcode":"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>